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ABSTRACT 


All  Naval  dental  treatment  facilities  (DTF)  worldwide  are 
required  to  submit  monthly  reports  containing  dental  records 
of  treatments  provided  and  overall  dental  readiness  to  COMNAV- 
MEDCOM,  in  Washington,  D.C.  These  reporting  requirements  are 
standardized  to  meet  not  only  the  requirements  of  the  Navy, 
but  also  as  input  to  the  DOD  mandated  Medical  Expense  and  Per¬ 
formance  System  (MEPRS) .  At  many  commands,  this  data  collec¬ 
tion  storage  and  reporting  effort  is  currently  performed 
manually,  adding  unnecessary  additional  administrative  burden. 

This  thesis  develops  a  computerized  database  system 
providing  increased  accuracy  and  productivity,  and  capable  of 
meeting  the  NAVMED  reporting  requirements.  The  Dental  Infor¬ 
mation  Retrieval  System  (DIRS)  developed  will  record  all 
treatments  provided  for  each  beneficiary  category  described  in 
N AVME  DCOM INST  6600. IB,  and  will  facilitate  internal  and 
external  daily,  weekly,  monthly  and  annual  reporting  require¬ 
ments.  An  important  design  consideration  is  providing  the 
DIRS  developed  with  the  requisite  capabilities  specified  by 
the'DTF's,  without  imposing  additional  hardware  requirements. 

NAVDENCLINIC  Long  Beach,  Ca.,  is  the  sponsoring  activity 
for  the  DIRS,  and  will  serve  as  the  test  site  for  system 
implementation.  If  the  system  is  successful,  Director  of 


Dental  Services,  San  Diego,  Ca.,  has  indicated  interest  in  the 
system  as  a  Navy-wide  managerial  tool. 
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I. 


INTRODUCTION 


A .  BACKGROUND 

Naval  Medical  Command  (NAVMEDCOM) ,  Washington,  D.C.,  is 
chartered  to  provide  general  and  specialized  health  and  dental 
care  for  active  duty  members  of  the  Navy  and  Marine  Corps  at 
ships,  posts,  and  stations  worldwide.  When  available,  this 
service  extends  to  other  eligible  beneficiaries;  members  of 
other  Federal  Uniformed  Services,  retirees  and  their 
dependents,  and  dependents  of  active  duty  personnel. 

To  meet  requirements  for  internal  and  external  budgeting, 
performance,  training  and  readiness  reporting,  NAVMEDCOM  tasks 
all  activities  providing  dental  care  to  submit  Dental 
Information  Retrieval  System  (DIRS)  reports  as  prescribed  in 
NAVMEDCOMTMST  6600. IB.  This  instruction  provides  guidance  for 
submission  of  monthly  reports  from  subordinate  Dental 
Treatment  Facilities  (DTF)  or  Regional  Headquarters  to 
COMNAVMEDCOM  in  Washington  D.C.  Procedures  lor  reporting 
dental  readiness  are  explicitly  specified  in  the  instruction, 
including  outlines  of  treatment  codes  and  the  associated 
composite  time  values  required  for  producing  mandated  monthly 
reports  used  as  input  to  the  Medical  Expense  and  Performance 
System  (MEPRS) .  MEPRS  is  a  Department  of  Defense  (DOD) 
mandated  report  that  is  prepared  at  NAVMEDCOM  from  input 


provided  by  subordinate  medical  and  dental  commands  in  the 
Department  of  the  Navy  (DON) . 

Commanding  officers  and  heads  of  dental  departments  at  all 
activities  providing  dental  care  are  responsible  for 
submission  of  NAVMED  6600/8,  the  DIRS  monthly  Treatment 
Report.  If  personnel  from  more  than  one  DTF  are  combined 
under  a  single  command,  then  the  senior  dental  officer  at  the 
headquarters  level  is  responsible  for  compliance  with  the 
NAVMEDCOMINST  directives  and  for  the  accurate  treatment  totals 
assigned  to  the  corresponding  provider. 

The  preface  to  NAVMEDCOMINST  6600. IB  states: 

The  ( COMNAVMEDCOM)  DIRS  is  a  computer-based  collection  and 
information  processing  system  designed  to  collect  data  on 
the  treatment  provided  to  all  eligible  beneficiaries.  The 
information  provided  by  the  DIRS  will  assist  Dental  Corps 
managers  at  all  levels  in  accomplishing  accurate  and 
realistic  planning  for  resource  requirements,  allocation, 
and  use.  [Ref.  1] 

Submission  of  the  NAVMED  6600/8  and  other  dental  reports 
follow  the  dental  command  hierarchy  depicted  in  Figure  1.1. 

At  NAVMEDCOM  level,  the  DIRS  is  a  computer-based  system. 
However,  the  DIRS  Treatment  Report  (NAVMED  6600/8) ,  the 
requisite  monthly  feeder  report  from  all  DTF's,  is  a  ten-pitch 
optical  character  recognition  (OCR)  form  that  presently  may 
only  be  prepared  manually.  It  is  this  mandated  submission 
format  and  data  collection  requirement  that  has  created  a  need 
for  the  development  of  computerized  DIRS  at  the  lower  echelon 
DTF's.  Although  some  commands  have  proceeded  with  in-house 
development  of  automated  DIRS,  none  have  been  successful  in 
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Figure  1.1  Organization  Chart 

providing  adequately  for  data  integrity  issues  such  as 
redundancy,  consistency  and  concurrency.  Most  systems  were 
created  by  non-ADP  personnel  with  little  or  no  formal  training 
in  database  design  issues,  hence  much  of  the  desired 
functionality,  especially  in  the  areas  of  updates  to  the 
database  and  supporting  documentation,  were  inadequately 
addressed  or  exhibited  poor  design. 

The  mandated  monthly  NAVMED  6600/8  report  resulting  from 
either  a  manual  or  computerized  DIRS  is  transcribed  via  OCR-A 
capable  typewriter,  and  the  resulting  original  form  is  mailed 
to  COMNAVMEDCOM .  Reports  submitted  for  a  given  month  are  to 
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be  received  no  later  than  the  15th  day  of  the  following  month. 
At  NAVMEDCOM  in  Washington,  D.C.,  these  reports  are  entered 
into  the  DIRS  via  OCR  reader.  Any  failure  in  the  ability  of 
the  OCR  reader  to  assimilate  the  correct  data,  caused  by 
ordinary  and  extraordinary  events  such  as  folds,  staple  holes, 
stains,  rips,  ink  too  light,  misaligned  characters,  etc., 
requires  report  resubmission  by  the  corresponding  DTF.  The 
weakness  of  such  a  system  is  obvious,  and  represents  a  major 
bottleneck  to  the  efficiency  and  success  of  the  reporting 
system . 

B.  STATEMENT  OF  PROBLEM 

The  problem  with  DIRS  is  twofold:  The  first  problem  is 
that  manual  systems  require  assignment  of  a  significant 
collateral  duty  to  a  dental  technician  (DT)  to  gather,  sort, 
compute  and  report  dental  treatment  information  submitted  by 
each  provider.  Each  individual  treatment  is  assigned  a 
composite  time  or  weighted  point  value.  The  time  savings 
offered  by  an  automated  system,  would  allow  better  use  of  the 
DT  assigned  to  this  task  in  more  critical  duties  related  to 
actual  patient  care.  The  second  problem  is  that  existing 
computerized  DIRS  applications  are  command  dependent;  lacking 
standardization  in  quality  and  capabilities  and  tailored  only 
for  a  specific  command.  The  presert  computerized  DIRS 
application  is  also  dependent  on  a  particular  database 
package.  For  example,  any  update  function  must  be  achieved 
via  the  specific  DBMS  used  to  develop  the  application  program. 
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This  dependency  is  costly  in  the  sense  that  given  a  DIRS 
system  programmed  using  a  commercial  database  package  such  as 
ORACLE  or  INGRES,  that  specific  package  must  first  be 
installed  on  the  personal  computer  (PC)  used  for  DIRS 
reporting.  The  personnel  operating  such  a  system  must  be 
familiar  with  the  nuances  and  features  of  the  particular 
database  package,  which  complicates  the  training  on  the 
system. 

A  solution  to  these  problems  was  hoped  to  be  found  in  the 
Dental  Management  Information  System  (DENMIS) ,  a  proposed 
tri-service  system,  which  had  its  first  module  (patient 
appointment  module)  tested  last  year  at  Headquarters  NDC  Long 
Beach,  Ca.,  with  unsatisfactory  results. 

Further  development  effort  on  the  DENMIS  and  on  individual 
modules  such  as  DIRS  was  halted  with  the  original  contractor. 
The  DENMIS  contract  was  relet  through  NARDAC,  Washington, 
D.C.,  with  proposed  testing  at  27  sites  in  1990.  According 
to  the  contract  firm,  the  proposed  DENMIS  will  require  an 
80386-based  personal  computer  to  function  properly.  This 
particular  specification  tends  to  limit  the  utility  of  the 
program  developed,  for  some  Dental  Treatment  Facilities, 
especially  small  or  deployed  DTF's  currently  lack  this 
additional  specified  hardware  requirement.  Recent  information 
indicates  that  the  contracted  DENMIS  system  will  not  include 
a  DIRS  module  as  a  result  of  insufficient  funding.  [Ref.  2] 
The  current  thesis  work  is  not  intended  to  replace  DENMIS,  but 
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to  provide  a  quality  DIRS  module  for  NAVDENCLINIC  Long  Beach, 
Ca.,  and  the  Director  of  Dental  Services,  San  Diego,  Ca., 
until  possible  future  delivery  of  a  contractor-developed  DIRS. 

The  identified  requirement  for  a  computerized  DIRS  coupled 
with  the  uncertain  future  of  DENMIS,  have  generated  renewed 
interest  in  the  development  of  a  proposed  flexible  PC-based 
DIRS  system  that  will  aid  lower  echelon  DTF ' s  in  meeting  the 
stringent  reporting  requirements  mandated  by  COMNAVMEDCOM . 

C.  SCOPE 

The  proposed  Dental  Information  Retrieval  System  (DIRS)  is 
intended  to  provide  a  stand-alone,  compiled,  non-command 
dependent  relational  database  system  and  associated 
applications  program.  The  system  is  necessary  to  support 
administration,  documentation  and  accounting  of  patient 
treatment  provided  by  dental  officers  and  dental  laboratory 
technicians.  The  software  system  development  life  cycle 
(SDLC)  will  be  used  to  develop  a  working  DIRS  (to  include: 
system  analysis,  design,  development,  documentation  in  the 
form  of  user's  manual,  implementation  and  training).  Research 
issues  are  listed  below: 

Identification  of  user  requirements. 

Examine  present  instructions  or  guidelines  for  DIRS. 

Determine  if  it  is  feasible  to  develop  a  DIRS's  system 
that  is  not  dependent  on  an  external  DBMS;  i.e.,  dBASE 
IV,  dBASE  III  PLUS,  ORACLE  or  any  other  off-the-shelf 
DBMS. 
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Determine  if  a  DIRS '  s  system  can  be  developed  that  is 
command  independent,  i.e.,  Unit  Identification  and/or 
provider (s)  code  not  hardcoded  in  source  code. 

Develop  a  system  to  support  multiple  clinics,  yet  account 
for  each  DTF  separately. 

-  Execute  critical  file  back-up  without  requiring  access  to 
an  external  DBMS. 

Organize,  sort,  and  index  files  without  access  to  an 
external  DBMS. 

The  goal  of  this  development  effort  is  an  imbedded  DBMS  in 
the  compiled  DIRS  application  that  can  be  used  on  any  IBM  PC 
compatible  system  with  a  minimum  20  megabyte  hard  disk 
commonly  found  throughout  the  U.S.  Navy  dental  community. 
Success  with  this  project  would  reduce  unnecessary 
off-the-shelf  database  purchases,  reduce  many  long  hours  of 
manual  data  collection  and  manipulation  to  produce  mandated 
reports.  Automation  will  improve  accountability  of  dental 
productivity,  and  will  provide  better  utilization  of  dental 
personnel . 

D .  METHODOLOGY 

Prior  to  development  of  a  computerized  DIRS,  the  current 
system  must  be  analyzed  and  the  needs  of  system  users 
identified.  A  four-phase  process  of  system  analysis  will  be 
followed:  study,  requirements  definition,  design  and 

implementation  phase. 

In  the  study  phase,  the  relative  characteristics, 
capabilities  and  deficiencies  of  the  current  system  are 
examined  and  documented. 
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Specific  objectives  in  gaining  a  thorough  understanding  of 
the  system  are: 

Identify  system  users  and  others  affected  by  the  current 
system. 

Identify  deviations  and  deficiencies  between  goals, 
purpose,  policies  and  objectives  of  the  present  system, 
and  actual  system  performance. 

Identify  functions  of  the  current  system  that  provide 
adequate  support  to  the  mission  and  users. 

Map  the  components  of  the  present  system,  and  analyze  the 
required  interaction. 

In  requirements  definition,  the  second  phase  of  systems 

analysis,  the  following  two  goals  were  identified: 

Identification  of  required  objects  and  their  structure. 

Identification  of  functional  components  for  each 
application  with  access  to  the  database. 

In  design  phase,  the  third  phase  of  systems  analysis,  the 

specific  actions  listed  below  must  occur: 

Transformation  of  objects  into  a  relational  design. 

Developing  the  functional  requirements  into  application 
design.  This  includes  detailed  formats  for  forms, 
reports,  menus,  and  logic  for  programs. 

Implementation  is  the  actual  transformation  of  relations, 
and  pseudo-code  developed  during  design  phase  into  files  and 
working  applications.  In  this  phase,  actual  coding,  testing, 
installation,  and  training  of  users  will  occur. 

E.  FEASIBILITY 

1 .  Cost 


The  developmental  cost  of  the  Dental  Information 
Retrieval  System  is  limited  to  the  personal  time  and  effort  of 
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the  thesis  participants.  Equipment  needed  for  system 
development  is  now  on  hand  either  at  the  Naval  Postgraduate 
school,  Monterey,  Ca.,  or  in  the  personal  possession  of  the 
thesis  team.  Implementation  and  training  at  the  test  site  is 
not  expected  to  exceed  two  working  days.  The  sponsoring 
activity;  Headquarters  Naval  Dental  Center  (NDC) ,  Long  Beach, 
Ca.  ,  has  offered  financial  support  for  the  travel, 
implementation,  and  training  costs  associated  with  this 
project.  Extensive  use  of  pull-down  menus,  simple  easy-to- 
follow  dialogue,  and  a  comprehensive  DIRS  user’s  manual  will 
simplify  training. 

2 .  Technical 

The  design  architecture  proposed  will  allow  the 
individual  DTF  to  store  one  year  of  provider's  treatment 
information  for  the  entire  command,  on  the  DIRS.  The  minimum 
hardware  requirement  is  stated  below; 

An  IBM-AT  compatible  computer  with  a  minimum  64 OK  RAM 

memory . 

20  megabyte  capacity  hard  disk. 

MS-DOS  version  3.0  or  later  release. 

An  OCR  10  pitch  printer. 

3 •  Schedule 

The  proposed  system  will  be  available  as  a  complete 
working  application  including  documentation,  by  March  of  1990. 
It  should  be  possible  to  develop  and  test  DIRS  in  one  to  two 
months.  Installation  and  user  training  is  not  expected  to 
exceed  two  to  three  days. 
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II.  USER  REQUIREMENTS 


A.  PRESENT  SYSTEM 

Each  dental  command  has  a  DIRS  to  meet  reporting 
requirements  mandated  by  COMNAVMEDCOM .  The  monthly  submission 
by  fleet  DTF's  of  the  NAVMED  6600/8  (DIRS  Treatment  Report), 
is  the  culmination  of  a  daily  manual  collection  and 
categorization  effort  by  each  provider  and  supporting  DT  at 
each  DTF. 

As  depicted  in  Figure  2.1,  data  origination  occurs  as  a 
dental  provider  (dentist,  dental  technician,  etc.),  performs 
a  treatment  or  multiple  treatments  on  a  patient  belonging  to 
one  of  nine  beneficiary  category  codes  (see  Figure  2.2).  Each 
provider  in  a  DTF  will  record  this  information  for  every 
patient  attended  during  the  reporting  period  (in  this  example, 
a  single  day)  on  a  Daily  Count  Sheet.  The  dental  technician 
assigned  responsibility  for  aggregating  this  data  insures  a 
corresponding  three-digit  provider  code  is  assigned  to  the 
respective  provider  treatment  counts  prior  to  producing  a 
daily  NAVMED  6600/11  (Appendix  I) .  Each  day  treatments  are 
performed  requires  a  NAVMED  6600/11  for  inclusion  in  the 
monthly  summation  of  provider  totals;  NAVMED  6600/8  (Appendix 
J) .  It  is  this  report  that  must  be  prepared  in  OCR  format  for 
eventual  submission  to  COMNAVMEDCOM,  Washington,  D.C.,  after 
routing  through  the  respective  chain  of  command.  Branch 
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clinics  operating  under  a  headquarter's  clinic  are  required  to 
submit  their  data  for  inclusion  in  an  aggregate  headquarters 
NAVMED  6600/8  report.  Independent  DTFs  submit  their  report 


PROVIOER  1  PROVIDER  *  PROVIDER  N 

14  ON  T  H  LY  TOTAL  MONTHLY  TOTAL  MONTHLY  TOTAL 


Figure  2.1  Current  Manual  DIRS  Data  Flow 
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directly  to  COMNAVMEDCOM .  In  both  cases,  report  receipt  in 
Washington  D.C.  is  required  no  later  than  15  days  following 
conclusion  of  the  reporting  period.  User  interviews  indicate 
that  report  preparation  may  require  several  days,  especially 
at  headquarters  commands.  Reports  must  be  tabulated  by 
individual  provider,  beneficiary  category  codes,  and  coded 
treatments  completed.  Each  beneficiary  code  listed  in  Figure 
2.2  must  have  individual  accounting  of  treatments  performed, 
for  each  provider  assigned  to  a  DTF. 


BENEFJCIARY  CODES: 

01  -  Active  Duty,  U.S.  Navy 

02  -  Active  Duty,  U.S.  Marine  Corps 

05  -  Active  Duty,  Other  Services 

08  -  Recruit,  U.S.  Navy  or  Marine  Corps 

09  -  Dependents  of  Active  Duty 

U.S.  Uniformed  Services  Personnel 

10  -  Dependents  of  Retired  or  Deceased 

U.S.  Uniformed  Services  Personnel 

11  -  Retired  Uniformed  Services  Personnel 

12  -  Other  Personnel  not  listed  in  Codes 

01  through  11  and  13 

13  -  Dependent  Children, 

_ (17  &  under  and  unmarried) _ 

Figure  2.2  Beneficiary  Code  Table 

Reporting  preparation  difficulties  are  compounded  by  the 
vast  number  of  most  frequently  performed  clinical  services 
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treatment  codes  (over  280) ,  and  over  82  laboratory  services 
codes.  "The  clinical  services  treatment  code  weight  factors 
are  based  on  time  values  and  are  termed  composite  time  values 
(CTV) .  A  CTV  of  1  equals  17  minutes."  [Ref.  1]  Similarly, 
each  laboratory  services  code  is  assigned  a  composite  lab 
value  (CI.V)  .  One  CLV  is  assigned  a  six  minute  value.  A  wide 
variance  in  possible  point  value  complicates  reporting;  in 
clinical  services,  for  example,  blood  pressure  recording  is 
assigned  a  CTV  of  .3,  while  fitting  for  a  partial  denture  with 
precision  attachments  is  assessed  a  25.9  CTV.  For  lab 
services  the  variance  is  greater;  from  1  CLV  for  issuing 
teeth,  to  an  assigned  CLV  of  220  for  creation  of  an  Andrews 
Bridge  (an  entire  dental  restoration) .  This  information  is 
valuable  as  a  management  tool  for  examination  of  historical 
trends,  administration  and  resource  allocation  decisions,  and 
in  comparison/analysis  of  various  ratios;  i.e.,  total  CTV's 
divided  by  number  of  providers,  CLV’s  by  available  time,  etc. 

The  submission  to  COMNAVME  DCOM  in  the  form  of  NAVMED 
6600/8  is  a  monthly  compilation  of  Daily  Treatment  Records 
from  all  providers  at  a  given  DTF.  The  Unit  Identification 
Code  (UIC)  identifies  the  activity  submitting  the  report. 
NAVMEDCOMINST  6600. IB  states  that  each  Dental  Treatment 
Facility  must  submit  the  OCR  format  NAVMED  6600/8  via  priority 
mail  to  arrive  at  COMNAVMEDCOM  "not  later  than  the  15th  day 
of  the  month  following  the  month  for  which  the  treatment  was 
provided."  [Ref.  1]  The  instruction  also  directs  that  a  copy 
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of  the  submission  be  mailed  to  the  "appropriate  geographic 
naval  medical  command  (geographic  NAVMEDCOM) . "  These  mandated 
stipulations  create  time  constraints  that  leave  little  or  no 
time  for  the  responsible  headquarters  command  to  review 
subordinate  clinic's  NAVMED  6600/8. 

While  the  current  technology  exists  within  the  DON  to 
expedite  reporting  system  requirements,  the  rigid  adherence  to 
the  OCR-A  typewriter  and  carbonized  form  creates  a  reporting 
bottleneck  causing  needless  delays  and  repetition.  The  time 
lost  in  preparing  and  submitting  the  NAVMED  6600/8  each  month 
is  valuable  time  that  could  be  spent  on  patient  care.  The 
present  system  can  support  only  one  clinic  and  lacks  the 
provision  for  data  import  to  meet  mandated  reporting  via  their 
respective  headquarters,  in  effect  rendering  each  DTF  an 
independent  command. 

B.  REQUIREMENTS  DEFINITION 

The  purpose  of  this  phase  is  twofold.  It  defines  data 
requirements  (objects)  that  must  be  represented  in  the 
database  and  outlines  functional  requirements;  (update, 
display,  and  control  mechanisms)  necessary  to  support  the 
Dental  Information  Retrieval  System.  User  requirements  are 
the  "blueprint"  for  database  design.  [Ref.  3]  Accurate 
identification  and  representation  of  user  requirements  is 
critical  to  the  success  of  the  entire  development  effort. 

An  object-oriented  methodology  will  be  used  to  define  and 
further  clarify  actual  user  requirements.  This  methodology 
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includes  the  identification  of  objects,  development  of  object 
views,  and  materialization  of  these  views  into  applications. 
"An  object  is  a  named  collection  of  properties  that 
sufficiently  describes  an  entity  in  the  user's  work 
environment."  An  entity  is  "a  class  of  things  that  exist  in 
the  users  business  environment."  [Ref.  3] 

1 .  Data  Requirements 

Objects  necessary  for  inclusion  in  the  database  were 
identified  by  examining  NAVMEDCOMINST  6600. IB,  current  manual 
DIRS  data  flow  (Figure  2.1),  and  from  personal  interviews  of 
dental  technicians  and  dental  managerial  personnel.  Through 
the  processes  described  above,  objects  were  identified  and 
transformed  into  object  diagrams  (Appendix  A)  . 

a.  Object  Description 

In  defining  the  requirements  of  a  database 
application,  it  is  important  to  identify  and  capture  those 
objects  that  accurately  describe  the  aspects  of  the  user's 
work  environment  which  the  database  is  intended  to  model. 
Recall  that  "an  object  is  a  structure  that  represents  an 
entity."  [Ref.  3]  Multi-valued  properties  are  allowed  to 
have  more  than  one  value,  and  may  themselves  be  objects  or 
non-object  properties.  "Object  properties  represent  other 
objects"  while  "non-object  properties  represent  descriptive 
characteristics"of  objects.  User's  environment  objects  and 
properties  identified  are  described  below.  Depictions  of 
objects  are  accomplished  through  the  use  of  object  diagrams 
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(see  Appendix  A.)  "An  object  diagram  describes  objects  in  the 
user's  world  and  their  relationship  to  one  another."  The 
seven  boxes  depicted  in  Appendix  A  each  represent  a  single 
object.  Listings  inside  each  box  contain  all  properties  of 
that  object.  Note  that  some  properties  listed  are  portrayed 
in  lowercase  letters,  while  others  are  enclosed  in  small  boxes 
and  are  written  in  uppercase  letters.  These  properties  are 
themselves  other  objects.  For  example,  the  PROPERTY 
"COMMAND"  inside  the  box  titled  "STATS  (HQ)"  denotes  that  the 
object  COMMAND  is  a  property  of  the  object  STATS  (HQ) .  The 
subscript  "MV"  beneath  some  of  these  boxes  denotes  that  the 
property  is  multi-valued. 

The  Provider  Object  represents  individual 
personnel  who  provide  direct  and  indirect  patient  care.  A 
laboratory  technician  performing  a  procedure  such  as  waxing  a 
crown,  is  an  example  of  indirect  patient  care.  A  dentist 
delivering  the  crown  is  an  example  of  direct  treatment. 
Individual  rank,  name,  and  duty  status  (active  duty,  reservist 
or  contractor)  are  properties  of  this  object.  The  multi¬ 
valued  Daily  object  is  also  a  property  of  the  Provider  object, 
relating  the  provider  with  the  properties  associated  with  the 
Daily  object. 

The  Treatment  (DIRS  Code)  Object  represents 
treatment  codes,  the  military  services-developed  series  of 
codes  adopted  from  the  American  Dental  Association  (ADA) 
Council  on  Dental  Care  Programs.  Each  treatment  is  assigned 
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a  unique  identifying  code,  description  of  treatment,  and  a 
composite  time  value  (CTV) .  There  are  approximately  300 
codes.  Treatment  codes  are  identified  in  full  and  can  be 
found  in  NAVMEDCOMINST  6600. IB.  The  proposed  DIRS  will 
include  the  list  of  codes  and  their  meaning,  to  eliminate  the 
inconvenience  of  looking  the  information  up  in  the 
NAVMEDCOMINST. 

The  Command  Object,  which  consists  of  the  Unit 
Identification  Code  (UIC) ,  the  command  name,  and  the  MEPRS 
codes,  identifies  the  submitting  unit.  The  MEPRS  code  is  also 
known  as  the  UCA  code,  and  is  used  only  for  NAVMEDCOM  Naval 
Hospitals  and  Naval  Dental  Commands.  The  four  digit  code  for 
each  work  center  is  required  on  each  NAVMED  6600/8  submission, 
and  delineates  the  type  and  location  of  dental  procedures 
performed.  The  Command  object  also  includes  the  multi-valued, 
Provider  and  Year  objects. 

The  Daily  Object  represents  entries  for  a 
particular  data  entry  session,  that  include  each  instance  of 
an  individual  provider  providing  a  treatment  to  a  patient  in 
one  of  the  nine  beneficiary  categories.  The  NAVMEDCOMINST 
does  not  specify  a  requirement  that  daily  treatment 
information  be  automated,  but  a  hardcopy  of  the  Daily 
treatment  work  sheets  must  be  kept  on-hand  for  two  years. 

In  order  to  support  both  headquarters  and  branch 
clinics,  three  additional  objects  have  been  identified.  The 
responsible  headquarter's  command  has  indicated  the  desire  to 
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maintain  a  year’s  compilation  of  information  on  all  its 
component  commands.  Each  branch  clinic  must  maintain  data 
specific  to  their  clinic  for  a  year.  Both  commands  want  to 
store  information  for  a  period  of  one  year,  but  neither 
command  has  large  capacity  ADP  storage  hardware.  Both  want 
the  capability  of  retrieving  data  by  month  in  the  appropriate 
format  stipulated  in  NAVMEDCOMINST  6600. IB.  For  these 
reasons,  a  Year  Object,  and  Monthly  Object  are  needed  to  track 
branch  clinic  information  and  a  Stats  (HQ)  Object  is  needed  to 
keep  all  statistical  information  on  all  its  subordinate 
commands.  A  Unit  Identification  Code  (UIC)  entity  is  required 
to  uniquely  identify  a  specific  DTF.  The  Year  and  Monthly 
objects  are  very  similar  in  structure.  Each  object  consists 
of  information  relevant  to  the  treatment  performed  on  a 
particular  beneficiary  category  code,  the  provider  performing 
treatment  and  provider  status,  and  the  calendar  month  the 
treatment  was  effected.  Object  definitions  are  provided  in 
Appendix  B. 

b.  Domain  Definitions 

In  addition  to  identification  of  required  objects, 
and  user  views  of  those  objects,  further  clarification  of  user 
requirements  is  achieved  through  specification  of  domain 
definitions.  A  domain  is  defined  as  "a  description  of  the 
allowed  values  of  an  attribute."  [Ref.  3,  p.  150]  Domain 
definitions  include  both  physical  descriptions  of  allowable 
data  values,  and  logical  descriptions  pertaining  to  attribute 
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meanings.  The  domain  definitions  specified  are  provided  in 
Appendix  C. 

2 .  Functional  Requirements 
a.  Data  Flow  Diagrams 

Using  the  object  requirements  identified  in  the 
previous  section,  and  proceeding  with  the  object-oriented 
methodology,  a  dataflow  diagram  (see  Figure  2.3  or  Appendix 
D)  was  developed  depicting  required  actions  on  objects 
identified. 

A  dataflow  diagram  portrays  the  business  functions  and  their 
data  interfaces.  Dataflow  diagrams  can  be  used  to  identify 
applications  and  the  data  they  use.  Four  symbols  are  used 
in  a  dataflow  diagram.  Internal  system  processes  are  shown 
in  circles,  while  external  processes  are  shown  in 
rectangles.  Data  interfaces  are  illustrated  with  named 
arrows,  and  stored  data,  including  the  database,  is  shown 
between  parallel  horizontal  lines.  [Ref.  3] 

As  depicted  in  Figure  2.3,  update  mechanisms  (add, 
edit  and  delete)  and  display  mechanisms  are  required  for  DIRS 
and  PROVIDER  woject.  Daily  transactions  cannot  be  recorded 
unless  valid  DIRS  or  provider  information  is  recorded  in  the 
database.  This  information  is  provided  by  either 
NAVMEDCOMINST  6600. IB  or  DTF  managers.  Both  provider  and  DIRS 
treatment  code  are  unique,  only  one  provider  may  be  assigned 
provider  code  100  for  example.  For  the  same  reason,  only 
treatment  code  "0120"  may  represent  a  periodic  oral 
examination.  The  proposed  system  shall  provide  update 
mechanisms  insuring  that  duplicate  records  will  not  be  created 
for  those  objects.  Management  assigns  provider  codes  to  new 
providers  reporting  onboard.  To  preserve  data  integrity,  a 
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DATA  FLOW  DIAGRAM 


Figure  2.3  DIRS  Data  Flow 
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current  provider  listing  will  be  generated  for  management 
review  and  to  assist  them  in  assigning  provider  codes  to  new 
personnel . 

The  COMMAND  object  will  be  created  only  once  upon 
initial  installation  of  the  proposed  system.  Command  and 
MEPRS  information  are  derived  from  COMNAVME DCOM INST  6600. IB 
and  DTF  management.  This  object  itself  serves  as  a  control 
mechanism.  Users  will  only  be  authorized  to  access  commands 
specified  in  this  object. 

The  heart  of  the  required  application  is  the 
creation  and  update  mechanisms  for  the  DAILY  object.  For  it 
is  through  these  mechanisms  that  the  MONTHLY  and  YEARLY 
objects  are  updated.  It  will  be  the  responsibility  of  the 
data  administrator  or  data  entry  clerk  to  input  provider  work 
information  which  will  update  the  DAILY,  MONTHLY,  and  YEARLY 
objects.  Appendix  E  delineates  update,  display  and  control 
mechanisms  for  each  object  described  above. 

A  STATS  (HQ)  object  is  created  and  updated  through 
monthly  and  yearly  information  submitted  by  subordinate 
commands.  A  headquarters  database  must  be  maintained  for  a 
minimum  of  one  year,  consisting  of  the  aggregate  provider 
production  information  for  each  subordinate  command.  This 
object  will  provide  management  with  the  central  depository  to 
meet  internal  and  external  reporting  requirements.  The 
dataflow  diagram  presented  in  Figure  2.4  represents  these 
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actions.  Appendix  E  delineates  update,  display  and  control 
mechanisms  for  the  STATS  (HQ)  object. 


Figure  2.4  STATS  (HQ)  Data  Flow 

b.  External  Control 

External  processes  will  augment  database  control. 
Access  to  the  system  for  display  of  information  will  be 
controlled  externally  by  the  user  command  limiting  physical 
access  to  the  computer  equipment  to  appropriate  personnel.  It 
will  be  left  to  physical  security  procedures  to  control 
routine  access  to  the  system's  information  display 
capabilities.  Similarly,  external  processes  will  be  used  to 
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help  regulate  database  updates.  The  user's  manual  (Appendix 
K)  will  provide  structured  guidelines  for  system  use  including 
data  update  procedures. 

c.  Other  Requirements 

During  the  interview  process,  several  problems 
were  identified.  Data  entry  may  not  be  accomplished  on  a 
daily  basis.  Provider's  daily  work  sheets  may  be  totalled  and 
submitted  at  the  end  of  the  work  week.  Even  if  the  provider's 
work  sheet  is  submitted  daily,  the  technician  entering  DIRS 
information  may  not  have  sufficient  time  to  input  data  until 
the  next  day  or  even  several  days  later.  The  DIRS  must  be 
flexible  enough  to  handle  this  type  of  erratic  schedule  of 
data  input.  The  DAILY  object  is  needed  to  verify  that  data 
entered  corresponds  to  the  data  reported  on  the  provider's 
work  sheet. 

Due  to  data  storage  limitations,  the  structure  of 
the  proposed  system  needs  to  offer  several  additional 
capabilities  to  users;  file  size  grows  only  as  required  by  the 
number  of  actual  instances  of  treatments  provided,  not  by 
arbitrary  structure  based  on  all  possible  treatments,  per  all 
beneficiary  categories  for  each  provider.  An  application  with 
relations  structured  in  this  manner  would  soon  exhaust 
available  data  storage  capacities  unless  frequently  purged. 
An  efficient  database  design  shall  allow  treatment  instances 
to  be  updated  and  totalled  in  year-to-date  totals  rather  than 
adding  an  additional  record,  yet  still  provide  data  extraction 
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capabilities  for  internal  and  external  reporting.  Appendix  H 
contains  examples  of  sample  reports. 

The  seven  objects  identified  earlier  are  required 
in  the  structure  of  the  proposed  DIRS  to  meet  the  following 
requirements : 

The  system  must  provide  update  mechanisms. 

Utility  functions  must  be  incorporated  into  the  system  to 
provide  easy  file  backup  and  file  organization  such  as 
indexing. 

The  system  dialogue  must  be  easy  for  non-ADP  personnel  to 
follow  and  use. 

The  system  must  have  the  capability  of  exporting 
requested  information  to  floppy  disk  and  at  the 
headquarters  level,  to  import  branch  clinic  data  to  the 
Headquarters  database. 

Several  reports  have  been  requested  by  the 
sponsoring  activity.  Headquarters  must  be  capable  of 
generating  the  required  branch  clinic  OCR  monthly  report 
directly  onto  NAVMED  6600/11.  Annual  treatment  reports 
similar  in  format  to  the  monthly  report  shall  be  printed  on 
request.  Summaries  and  full  Providers'  performance  reports 
also  shall  be  available  on  request.  Individual  provider 
reports  shall  be  generated  monthly  and  submitted  to  the 
corresponding  provider  for  his  or  her  own  personal  performance 
information. 

An  additional  requirement  identified  by  the 
sponsoring  activity,  as  discussed  previously,  is  support  for 
multiple  DTF's  under  one  command.  During  user  interviews,  it 
was  determined  that  the  proposed  DIRS  must  be  capable  of 
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supporting  up  to  nine  DTF's  under  a  single  Headquarters 
command.  Further,  with  multiple  DTF's,  the  possible  variety 
of  hardware  configurations  requires  that  the  proposed  DIRS  be 
generalized  or  "generic"  to  support  the  varied  functions  and 
requirements  of  a  specific  DTF.  Though  it  may  not  always  be 
the  case  in  systems  analysis  and  design,  in  this  instance,  the 
users'  view  of  the  objects  to  be  captured  by  the  DIRS, 
coincides  closely  with  the  actual  application  functional 
requirements  used  to  model  the  users'  view  of  the  system. 

The  computerized  DIRS  proposed  and  developed  in 
the  scope  of  this  thesis  will  meet  the  reporting  requirements 
of  a  Headquarters  Clinic  with  up  to  nine  subordinate  DTF's. 
Through  the  user-interview  process  and  dental  clinic  command 
structure  review,  the  provision  to  support  up  to  nine  DTF's  in 
the  proposed  program  was  identified  to  allow  future  expansion 
of  the  program  in  the  event  of  dental  command  reorganization, 
without  requiring  modification  of  the  database  structure. 
Currently,  NAVDENCLINIC  Long  Beach,  Ca.  ,  is  one  of  the  largest 
DTF  Headquarters  commands  with  five  subordinate  DTF's. 

In  addition  to  the  required  features,  the  proposed 
system  will  allow  subordinate  units  to  report  their  monthly 
totals  via  either  modem  or  "floppy"  medium  to  their 
Headquarters  Clinic.  At  the  Headquarters  level  in  the 
proposed  DIRS,  the  input  of  the  subordinate  DTF's  will  be 
combined  to  generate  the  requisite  NAVMED  6600/8  for 
submission  to  COMNAVMEDCOM.  The  proposed  DIRS  offers  the 
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elimination  of  much  of  the  manual  handling  and  transcribing  of 
daily  count  sheets,  and  offers  accurate  computerized 
completion  of  the  OCR-A  NAVMED  6600/8. 

Update,  Display  and  Control  Mechanisms  required 
for  the  DIRS  may  be  found  in  Appendix  E. 


26 


III.  SYSTEM  DESIGN 


The  third  phase  of  the  systems  analysis  process  is  system 
design.  In  this  phase,  the  basis  for  the  underlying  structure 
of  the  database  is  delineated  and  built.  The  system  design 
phase  is  sub-divided  into  the  logical  design  phase  and 
application  design  phase.  The  foundation  established  in  the 
design  phase  is  critical  to  successful  development  and 
maintenance  of  DIRS.  The  objective  of  logical  database  design 
is  to  translate  the  system  blueprint  identified  in  the 
requirements  phase  and  to  develop  a  set  of  relation  diagrams, 
relation  definitions,  domain  definitions  and  a  list  of 
constraints . 

A  number  of  approaches  to  database  design  exist,  and  a 
brief  discussion  of  some  of  the  relevant  issues  includes  the 
concepts  of  relations,  keys,  relationship  constraints  and 
normalization.  The  second  phase  of  system  design,  application 
design,  will  describe  the  actual  scope  of  DIRS,  control 
mechanisms  used,  a  description  and  depiction  of  the  menu 
hierarchy. 

A.  LOGICAL  DATABASE  DESIGN 

The  relational  database  model  will  be  used  to  develop  the 
logical  design  of  DIRS.  This  model  translates  the  objects 
identified  from  analysis  performed  during  the  requirements 
phase  into  a  relational  design.  The  relation  is  logically 
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equivalent  to  a  file,  which  contains  rows  and  columns.  A  row 
in  a  relation  table  represents  a  record  or  tuple.  Each  column 
in  a  relation  is  termed  an  attribute  or  field.  A  process 
known  as  normalization  is  used  to  collect  related  data 
properties  into  robust  well-designed  relational  (relation) 
tables.  A  well-structured  design  will  “allow  rows  to  be 
inserted,  deleted,  and  modified  without  resulting  in 
inconsistencies  or  errors  in  the  stored  data.”  [Ref.  3] 
Normalization  serves  to  identify  and  eliminate  these 
modification  anomalies.  Relations  which  correspond  to  DIRS 
are  graphically  depicted  in  Appendix  F. 

1.  Normalization 

Gathering  or  grouping  of  properties  or  data  items  into 
relations  is  an  important  aspect  of  database  design.  This 
process  of  "normalization"  is  used  to  eliminate  database 
design  weaknesses  or  flaws.  These  problems  or  "anomalies"  as 
they  are  called,  can  result  in  inadvertent  deletion  of  facts 
in  a  relation,  or  artificial  and  unintended  restrictions  on 
entity  insertion.  These  modification  or  update  anomalies  are 
termed  deletion  anomalies  or  insertion  anomalies  respectively. 
The  theoretical  framework  concerning  proper  database  design  is 
derived  from  early  database  design  work  of  E.F.  Codd  who 
provided  the  definition  of  possible  normal  forms  that 
relations  may  take.  Normalization  is  the  process  by  which  we 
"troubleshoot"  the  database  structure  to  identify  and  remove 
anomalies  discovered.  To  do  this,  data  items  or  properties 
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are  grouped  into  relations  as  previously  discussed.  Object 
diagrams  provided  in  Appendix  A  and  relation  diagrams  provided 
in  Appendix  F  depict  groups  of  related  properties  upon  which 
normalization  is  based.  All  relations  are  in  at  least  first 
normal  form.  In  the  relations  created  within  the  scope  of 
this  thesis,  each  is  at  least  in  third  normal  form  (3NF) .  "A 
relation  is  in  third  normal  form  if  it  is  in  second  normal 
form  and  has  no  transitive  dependencies.”  [Ref.  3:p.  14  3] 
Second  normal  form  is  defined  as  a  relation  in  which  "all  non¬ 
key  attributes  are  dependent  on  all  of  the  key."  [Ref.  3:  p. 
142] 

2 .  Keys 

"A  key  is  a  group  of  one  or  more  attributes  that 
uniquely  identifies  a  row.  Every  relation  has  at  least  one 
key.  Sometimes  the  key  is  one  attribute."  [Ref.  3:p.  139] 
In  the  example  provided  in  Appendix  F,  the  keys  are 
underlined.  In  the  PROVIDER  object,  the  underlined  attribute 
is  Prov  Code,  a  three  digit  code  which  serves  to  uniquely 
identify  any  provider  in  the  system.  It  is  possible  that  a 
group  of  attributes  will  be  required  to  "functionally 
determine"  (serve  as  a  key  to  uniquely  identify)  other  non-key 
attributes . 

3 .  Relations 

Relations  are  created  by  examining  object  diagrams 
(Appendix  A)  to  determine  relationships  among  objects 
(depicted  in  Appendix  F)  ,  then  transforming  these  objects  into 
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relations  such  as  those  described  below.  Depiction  of  an 
object  may  be  relatively  simple  or  may  require  the  composition 
of  several  relations.  Database  objects  (Appendix  A),  and 
relation  diagrams  (Appendix  F)  provide  examples  of  such 
composition.  A  simple  object  contains  only  single-valued, 
non-object  properties,  and  may  be  represented  by  a  single 
relation.  A  composite  object  contains  one  or  more  non-object 
multivalued  properties,  and  requires  more  than  one  relation 
for  their  representation.  A  compound  object  contains  at  least 
one  object  property,  requiring  translation  of  that  object  into 
a  minimum  of  two  relations.  As  an  example,  the  MONTHLY  object 
in  Appendix  A  contains  the  object  property  COMMAND  and  the 
multivalued  object  DAILY.  Each  of  the  seven  objects  in 
Appendix  A  is  a  compound  object,  containing  at  least  one  other 
object  property  each  depicted  by  its  own  relation  as  depicted 
in  Appendix  F.  [Ref.  3] 

4 .  Relationships 

A  binary  relationship  involves  only  two  record  types. 
Whereas  an  object  was  converted  on  a  one-to-one  basis  into  a 
relation  (record  type) ,  relationships  between  those  record 
types  are  not  necessarily  limited  to  one-to-one.  In  fact,  in 
this  database  the  majority  of  relationships  are  one-to-many. 
Referring  again  to  the  relation  diagrams  of  Appendix  F,  a 
given  STATS  (HQ)  may  have  multiple  commands  associated  with 
it,  as  indicated  by  the  "fork”  on  the  command  end  of  the 
connecting  line.  Similarly,  a  command  can  have  many  providers 
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and  a  provider  will  provide  many  treatments  to  many 
beneficiary  category  codes  during  the  course  of  a  daily 
(visit) . 

There  are  a  number  of  classifications  pertaining  to 
the  degree  of  relationship  that  exits  between  objects,  varying 
in  complexity  from  no  relationship  between  objects  (0:0),  to 
a  many-to-many  relationship  (M: N) .  For  example,  in  a  one-to- 
one  (1:1)  relationship,  one  record  is  related  to  only  one 
other  record  of  another  type.  Additional  explanation  is 
required  for  notation  used  in  Figure  3.1  and  Appendix  F,  to 
indicate  the  type  of  relationship  between  record  types. 
Beyond  the  "forked"  end  of  the  line  which  is  used  to  indicate 
a  "many"  (as  in  one-to-many)  ,  on  the  line  connecting  two 
objects  or  relations  together,  there  may  be  either  a  circle  or 
a  bar.  This  notation  is  found  on  both  ends  of  the  line 
connecting  the  records,  and  is  used  to  describe  an  optional  or 
mandatory  association  between  records.  These  associations  are 
a  type  of  relationship  constraint. 

5 .  Relationship  Constraints 

Relationship  constraints  such  as  those  presented  in  a 
simplified  version  of  DIRS  Relationships  are  provided  in 
Figure  3.1  below,  with  the  detailed  relationship  structure 
provided  in  Figure  3.2  and  Appendix  F.  If  a  relationship  is 
mandatory,  a  bar  will  be  found  perpendicular  to  the  opposite 
end  of  the  line  (side  closest  to  the  mandatory  association) . 
In  the  case  of  the  COMMAND  and  PROVIDER  objects  in  Figure  3.1, 
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Figure  3 . 1  DIRS  Relationships 

it  is  mandatory  that  a  COMMAND  have  a  PROVIDER,  and  that  a 
PROVIDER  have  a  COMMAND.  However,  the  circle  found  nearest 
STATS  (HQ)  on  the  line  connecting  COMMAND  and  STATS  (HQ) 
indicates  that  while  STATS  HW  must  have  a  COMMAND  associated 
with  it,  a  COMMAND  may  have  a  (HQ)  associated  with  it,  but  it 
is  not  mandatory,  as  COMMAND  could  stand  alone. 

To  accommodate  the  nuances  of  this  reporting  environment, 
and  attain  user  functional  requirements,  the  structure  of 
database  object  relationships  depicted  in  Figure  3.2  was 
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developed.  Database  relations  identified  remain  identical  to 
those  represented  above  in  Figure  3.1.  The  STATS  (HQ) 
relation  consists  of  the  key  attribute,  UIC  and  each  attribute 
belonging  to  COMMAND.  UIC  can  serve  as  a  key  attribute  for 
each  relation  because  this  five-number  code  is  uniquely 
assigned  to  individual  units.  Relations  containing  other 
relations  are  identified  by  attribute  names  presented  in  all 
capital  letters  (with  the  exception  of  UIC) .  COMMAND,  then, 
contains  two  other  relations;  PROVIDER  and  YEAR,  each 
containing  all  attributes  displayed  within  their  respective 
boxes  above,  and  in  both  appendices  A  and  B.  The  Name 
attribute  refers  to  Navy-assigned  command  plain  language 
addresses,  while  MEPRS  Code  describes  the  four-digit  work 
center  code  required  on  DOD  dental  reports.  COMMAND  has 
obvious  relationships  with  PROVIDER  and  YEAR,  as  diagrammed  by 
vertical  lines  connecting  these  relations,  and  more  subtle 
relations  through  these  two  relations  to  all  other  relations. 
No  object  exists  in  isolation.  It  must  be  tied  (related)  to 
at  least  one  other  object.  These  relations  may  be  optional 
(circles)  or  mandatory  (short  horizontal  line)  as  described 
earlier,  and  evidenced  in  Figure  3.2. 

YEAR,  as  defined  by  key  relations  COMMAND  and  MONTHLY, 
also  contains  an  individual  attribute  for  each  beneficiary 
category  code  listed  in  Figure  2.2. 

In  this  manner,  all  treatments  performed  on  members  of  a 
specific  beneficiary  code,  for  a  particular  month  and  at  a 
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STATS  (HQ) 


Figure  3.2  DIRS  Relation  Diagram 


specific  command,  are  delineated  and  totalled  separately. 
Similar  structuring  of  attributes  contained  in  both  MONTHLY 
and  DAILY,  allows  provisions  for  data  extraction  or 
combination,  while  always  retaining  identification  of  data 
origin.  For  example,  PROVIDER  contains  the  key  attribute  Prov 
Code,  in  addition  to  attributes;  first  name,  last  name,  rank, 
duty  status,  and  the  DAILY  object.  This  structure  means  that 
if  a  provider  performs  a  treatment  on  a  specific  day,  each 
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attribute  of  TREATMENT;  DIRS  code,  description  of  treatment, 
composite  value  and  DAILY,  is  included  in  data  specific  to 
that  provider.  To  identify  a  unique  DAILY  object  instance; 
PROVIDER,  TREATMENT  and  date,  together  serve  as  keys.  User 
requirements  identified  the  necessity  for  storage  of  a  year  of 
DIRS  data  on  disk  at  a  time.  To  support  this  specification, 
the  DAILY  relation  is  designed  as  a  temporary  object,  with 
data  values  added  to  update  MONTHLY,  at  each  convenient  data 
entry  session.  Structured  in  this  manner,  all  required  data 
manipulation  capabilities  are  supported  with  minimum  disk 
storage  overhead.  Inclusion  of  daily  beneficiary  category 
totals  to  DAILY,  permits  accurate  characterization  and 
summation  by  category,  stats  (HQ) ,  individual  command,  year, 
month,  provider  or  treatment,  for  a  particular  instance  or 
total  to  date. 

The  structure  described  above  offers  several  advantages  to 
users;  file  size  grows  only  as  required  by  the  number  of 
actual  instances  of  treatments  provided,  not  by  arbitrary 
structure  based  on  all  possible  treatments,  per  all 
beneficiary  categories  for  each  provider.  An  application  with 
relations  structured  in  this  manner  would  soon  exhaust 
available  data  storage  capacities  unless  frequently  purged. 
Efficient  database  design  allows  treatment  instances  to  be 
updated  and  totalled  in  year-to-date  totals  rather  than  adding 
an  additional  record,  yet  still  provide  data  extraction 
capabilities  for  internal  and  external  reporting.  Several 


35 


reports  are  supported  in  addition  to  provisions  for  automatic 
formatting  and  generation  of  the  required  monthly  NAVMED 
6600/8  using  an  OCR  font  printer.  User  desires  for  daily, 
monthly,  annual,  provider  statistics  and  major  treatment 
reports  shall  be  supported  options  in  the  Report  menu. 
Additional  provisions  for  file  import/export  and  maintenance 
shall  be  supported  as  described  in  the  file  utilities  menu 
section.  Support  requests  for  possible  expansion  of  up  to 
nine  subordinate  DTFs  under  a  single  headquarters  command  is 
provided  in  accordance  with  user  criteria.  This  support  means 
that  data  from  subordinate  commands  exported  to  a  headquarters 
may  be  sub-totalled  in  as  many  as  ten  total  categories. 
Additional  features  are  discussed  under  menu  hierarchy 
descriptions  later  in  this  chapter. 

B.  APPLICATION  DESIGN 

In  following  the  object-oriented  methodology,  the 
application  design  phase  will  include  determination  of  number 
and  scope  of  applications,  design  control  mechanisms  for 
identified  applications,  and  identify  specific  procedural 
logic.  Additional  considerations  include?  design 

materializations,  database  security  and  integrity. 

The  data  flow  diagrams  developed  in  the  user  requirements 
phase  to  help  document  flows  of  information,  identify  scope  of 
required  information  needs,  and  describe  required  structure  of 
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the  organization,  are  used  in  the  current  phase  to  assist  in 
the  creation  of  the  functional  hierarchy. 

1 .  Application  Control  Mechanisms 

"An  application  is  the  user's  interface  with  the 
database."  [Ref.  3]  This  interface  must  include  the  capacity 
for  recognizing  when  data  values  entered  are  of  an  appropriate 
type  and  are  within  the  intended  range  for  the  respective 
field.  The  users  and  developers  consider  extensive  use  of 
menus  as  the  most  appropriate  user-system  interaction  method 
for  a  given  application.  On-screen  templates  (or  masks,  as 
previously  discussed)  will  aid  data  entry  process  by 
restricting  allowable  data  types  (alphabetic,  numeric,  etc.) 
to  the  appropriate  field.  Pop-up  help  screens  provide 
additional  control  in  guiding  users.  Most  DIRS  on-screen 
messages  are  self-explanatory.  Pre-established  escape 
procedures,  such  as  pressing  any  key  on  the  initial  or  first 
blank  field  will  allow  users  to  abort  an  operation  and  return 
to  a  previous  menu,  or  to  exit  the  system  entirely.  An 
additional  escape  provision  is  available  from  within  any  level 
by  pressing  the  escape  key. 

Intuitive  feel  and  simplicity  of  design  allow  not  only 
shortened  operator  training  time,  but  also  permits  the 
developers  to  limit  deviations  from  the  acceptable  range  of 
values  for  a  given  task  or  command.  Consistent  use  of 
function  keys  to  provide  case  sensitive  help  screens  and 
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standardized  conventions  for  interfacing  with  the  application, 
also  streamline  user  familiarity  process. 

As  previously  stated,  to  accommodate  the  wide  variety 
in  computer  literacy  existing  among  potential  system  users,  a 
menu-driven  application  was  selected  as  the  most  appropriate 
application  control  mechanism.  The  next  design  step  required 
the  determination  of  menu  hierarchy.  Furthermore,  it  was 
determined  that  an  object/action  approach  would  best  serve 
user  needs.  An  object/action  approach  means  "the  highest- 
level  menu  offers  the  user  a  list  of  objects  that  might  be 
processed,  and  lower-level  menus  enable  the  user  to  indicate 
the  action  to  be  taken  on  the  selected  object."  [Ref.  3] 

An  important  design  consideration  for  DIRS  developed 
in  the  course  of  this  thesis  is  not  limiting  the  system  to 
only  one  command.  For  example.  Unit  Identification  Code 
(UIC) ,  command  name  and  UCA  code  must  not  be  hardcoded  in  the 
program.  This  requirement  will  be  accomplished  upon  initial 
installation  of  the  system.  A  memory  file  will  be  created  at 
that  time  containing  the  UIC,  Command  name,  and  related  UCA 
codes  for  the  appropriate  command.  Creation  of  this  object  as 
a  memory  file  within  random  access  memory  (RAM)  creates 
efficiency  gains,  saving  multiple  disk  seek  and  access  times. 
This  object  is  frequently  called  as  a  visual  aid  in  the  form 
of  a  pop-up  menu.  As  an  example,  a  subordinate  command  is  not 
required  to  reenter  its  UIC  for  each  instance  of  DIRS  data 
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input  for  a  daily  transaction,  as  object  relation  design 
results  in  automatic  updates  to  related  attributes. 

C.  MENU  HIERARCHY  DESCRIPTIONS 

Menus  used  in  the  DIRS  application  were  derived  from  an 
analysis  of  user  requirements  and  data  flow  diagrams.  Menus 
corresponding  to  these  diagrams  and  structures  are  briefly 
described  in  the  following  section.  Figure  3.3  depicts  the 


menu  structure  hierarchy  which  provides  graphic  information 
pertaining  to  specific  applications,  objects,  or  tasks 
assigned  to  a  block,  module,  or  sub-module  supported. 
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1 .  Main  Menu 


DIRS  main  menu  shall  offer  system  user  options 
depicted  in  Figure  3.4.  In  every  menu  screen  provided,  an 
option  may  be  selected  by  highlighting  the  desired  selection 
or  by  typing  the  first  letter  of  the  desired  option.  The 
final  option  available  on  each  menu  screen  is  a  provision  for 
exiting  to  the  next  higher  level  menu,  or  in  the  case  of  the 
main  menu,  exiting  DIRS  to  the  operating  system. 

As  depicted  in  the  following  diagrams,  each  menu 
screen  in  the  menu  hierarchy  exhibits  common  structure, 
consisting  of  three  distinct  parts.  User  information  is 
provided  in  part  A,  with  DTF  command  name,  system  name, 
current  time  and  date,  and  screen  number  identified.  Part  B 
presents  available  menu  options,  part  C  provides  option 
selection  instructions  and  error  message  display. 


A 


B 


C 


Figure  3.4  Main  Menu  Screen 


Heading 


NAVAL  DENTAL  CLINIC,  USN  13:17:17  01/13/90 

DENTAL  INFORMATION  RETRIEVAL  SYSTEM  SCREEN  #  1.0 


MAIN  MENU 

INPUT  DIRS  DATA 
CHANGE  DIRS  CODES 
UPDATE  PROVIDER  CODES 
QUERIES 

FILE  UTILITIES 
HEADQUARTERS  ONLY 
QUIT 


USE  UP  AND  DOWN  CURSOR  KEYS  ti  TO  HIGHLIGHT  ITEM  AND 
PRESS <RETURN> 


Prompt  &  Status  Box 
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To  operate  DIRS,  users  shall  enter  the  first  letter 
which  corresponds  to  the  item  in  the  menu  body  to  be  selected, 
or  move  the  arrow  keys  (ti)  to  highlight  an  option.  All  menus 
have  a  RETURN  option  to  return  to  next  higher  menu  in  the 
hierarchy. 

a.  Input  DIRS  Data 

The  first  screen  that  will  appear  when  selecting 
option  one  (INPUT  DIRS  DATA)  is  displayed  below  (Figure  3.5). 
Enter  "Y"  (yes) ,  if  the  displayed  month  is  the  desired  month 
for  data  entry.  Enter  "N"  (no)  to  select  another  month.  When 
"N"  is  selected  a  window  will  appear  displaying  options  that 
may  be  keyed  in  at  the  prompt  (see  open  month  screen  below) . 
The  default  month  (open  month  on  screen)  is  the  current 
calendar  month  based  on  the  computers  system  clock. 


NAVAL  DENTAL  CLINIC,  USN  08:05:14  01/13/90 

DENTAL  INFORMATION  RETRIEVAL  SYSTEM  SCREEN  #  1.1.1 

OPEN  MONTH  IS  JANUARY 

IS  THIS  CORRECT?  Y/N 

Figure  3 . 5  Month  Prompt  Screen 

To  select  the  correct  month,  the  three  letter 
abbreviation  is  entered  at  the  prompt.  For  example,  typing 
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JUN  in  the  month  selection  screen  will  open  that  month  for 
data  entry.  Once  the  desired  month  has  been  opened,  the 
provider  prompt  screen  will  follow  (Figure  3.6). 


NAVAL  DENTAL  CLINIC,  USN  09:02:20  01/13/90 

DENTAL  INFORMATION  RETRIEVAL  SYSTEM  SCREEN  #  1.1.1 


JAN 

JUL 

FEB 

AUG 

MAR 

SEP 

APR 

OCT 

MAY 

NOV 

JUN 

DEC 

ENTER  THREE  LETTERS  OF  NEW  MONTH: 


Figure  3.6  Month  Selection  Screen 


In  selecting  a  provider,  the  provider  code  may  be 
entered  directly  if  the  code  is  known,  or  by  pressing  the 
<HOME>  key,  an  additional  window  with  the  valid  provider  codes 
assigned  to  the  reporting  command  will  pop  up.  From  the 
available  valid  provider  codes  on  screen,  the  corresponding 
number  that  matches  the  desired  provider  code  may  be  entered. 
(See  Figure  3.7  and  Figure  3.8.) 

To  select  a  valid  provider,  enter  the  matching 
number  in  the  leftmost  column,  i.e.:  entering  number  "l" 
would  select  provider  100;  CDR  Navy.  The  provider  code  may 
also  be  entered  directly  on  the  provider  input  screen.  This 
method  of  provider  data  entry  provides  a  method  to  check  the 
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NAVAL  DENTAL  CLINIC,  USN  08:18:58  01/13/90 

DENTAL  INFORMATION  RETRIEVAL  SYSTEM  SCREEN  #  1.1.1 


PROVIDER  CODE: 


ENTER  PROVIDER  CODE  OR  PRESS  <HOME>  FOR  HELP 


Figure  3 . 7  Provider  Prompt  Screen 


NAVAL  DENTAL 

CLINIC, 

USN 

08:18:58  01/13/90 

DENTAL  INFORMATION  RETRIEVAL  SYSTEM  SCREEN  #  1.1.1 

PROVIDER 

CODE 

RANK 

NAME 

1. 

100 

CDR  ' 

NAVY,  JOSEPH 

2. 

200 

LT 

NAVY,  SON 

3  . 

300 

LT 

MESIAL,  DECAY 

4. 

400 

CAPT 

TOOTH,  DECAY 

5. 

455 

LT 

RESERVE,  DENTIST 

6. 

500 

CDR 

BUCKLE,  PIT 

7. 

600 

LT 

LINGUAL,  DISTAL 

8. 

700 

ADM 

DENTAL,  SERVICE 

PRESS  NUMBER 

OF  ITEM, 

RETURN  TO 

CONTINUE,  OR  "Q"  TO  QUIT 

Figure  3.8  Provider  Selection  Screen 


provider  code  file  to  validate  a  correct  provider  code  for  the 
reporting  unit.  Entering  an  erroneous  code  (a  code  not 
currently  in  the  provider  code  file)  results  in  an  error 
message  indicating  that  fact,  and  further  prompts  the  user  to 
enter  another  code. 

When  the  provider  field  is  correctly  entered,  the 
screen  displayed  in  Figure  3.9  will  follow,  prompting  the  user 


43 


to  enter  a  valid  treatment  code.  As  previously  discussed,  to 
escape  the  DIRS  entry  routine,  press  <RETURN>  at  a  blank  DIRS 
f je]d. 

NAVAL  DENTAL  CLINIC,  USN  08:05:14  01/13/90 

DENTAL  INFORMATION  RETRIEVAL  SYSTEM  SCREEN  #  1.1.2 

Entering  Data  for  Provider:  CDR  JOSEPH  NAVY  CODE:  100 


PRESS  THE  <HOME>  KEY  FOR  A  LIST  OF  DIRS  CODES  TO 
SELECT  FROM. 

PRESS  <RETURN>  ON  AN  EMPTY  FIELD  TO  RETURN  TO  THE 
MAIN  MENU. 


ENTER  DIRS  CODE: 

Figure  3 . 9  DIRS  Code  Prompt 

Pressing  the  <HOME>  key  will  display  all  valid 
DIRS  codes  (Figure  3.10).  DIRS  treatment  code  may  also  be 
entered  directly  on  the  DIRS  prompt  screen  or  the  <HOME>  key 
may  be  used  to  assist  the  user  in  the  event  that  correct  DIRS 
codes  are  unknown.  This  help  function  is  not  a  mandatory 
input  procedure. 

To  select  a  DIRS  treatment  code,  the  corresponding 
number  displayed  in  the  leftmost  column  is  selected  by  typing 
the  appropriate  number  (,,l,,-,,9” )  .  Pressing  the  <Page  Down> 
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Figure  3.10  DIRS  Code  Selection  Screen 


or  <Page  Up>  keys  will  scroll  through  the  list  to  display 
other  treatment  codes . 

Data  entry  for  an  individual  provider  is 
accomplished  using  screen  1.1.3  depicted  in  Figure  3.11  by 
entering  in  the  correct  quantity  of  procedures  completed  in 
each  dental  beneficiary  category.  The  <RETURN>  key  is  used 
to  move  the  cursor  to  the  next  field  for  data  entry.  The 
steps  listed  above  are  repeated  until  the  user  has  completed 
data  entry  for  a  particular  provider.  Data  entry  error 
corrections  are  accomplished  in  a  number  of  ways.  The  user  is 
prompted  with  the  following  query  at  the  bottom  of  screen 
1.1.3?  "Is  this  data  correct?  Y/N."  A  negative  response 
indicated  by  typing  the  "N"  key,  will  allow  the  user  to 
reenter  the  correct  data.  The  user  may  overwrite  the  data 
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Figure  3.11  Daily  Input  Screen 


displayed  on  screen  by  moving  the  cursor  using  arrow  keys  to 
the  correct  field  and  reentering  the  correct  quantity. 
Deletion  and  editing  of  values  previously  entered  for  a 
particular  month  is  accomplished  by  selecting  the  desired 
month,  provider,  and  treatment,  and  entering  an  appropriate 
negative  value  to  either  cancel  or  modify  the  monthly  total 
for  the  selected  record.  To  return  to  the  main  menu,  the 
<RETURN>  key  is  pressed  with  the  cursor  on  a  blank  DIRS  input 
field  or  typing  "Q"  when  prompted  from  the  help  screen.  When 
a  month  and  provider  have  been  selected,  the  user  may  continue 
adding  new  treatment  data  without  the  requirement  of  returning 
to  the  main  menu  for  each  instance.  To  enter  data  for  another 
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provider,  users  must  return  to  the  main  menu  and  select  the 
desired  month  and  treatments.  The  system  shall  default  to  the 
month  of  last  data  entry.  Upon  termination  of  a  data  entry 
session,  a  final  query  will  prompt  the  user  with  the  following 
message;  "Do  you  wish  to  save  this  data?  Y/N."  Selecting  "N" 
will  not  save  the  data  entered  during  the  session.  This 
particular  feature  is  provided  as  another  control  mechanism, 
allowing  the  user  to  correct  or  terminate  a  data  entry  session 
without  arbitrary  input  of  inadequately  screened  or  inaccurate 
data  to  the  database.  Selecting  "Y"  will  automatically  result 
in  appropriate  updates  to  the  Daily,  Monthly,  and  Yearly 
object  files.  Selection  of  "Y"  will  also  result  in  the 
display  of  the  following  messages  in  the  status  box  of  the 
menu  screen  (part  C)  ;  "Adding  to  Monthly  Total"  and  "Adding 
to  Yearly  Total,"  informing  the  system  user  of  action  in 
progress.  Again,  listing  command  providers  is  provided  as  a 
convenience  to  the  system  user. 

b.  Change  DIRS  Codes 

Selection  2  from  the  main  menu  (CHANGE  DIRS  CODES, 
Figure  3.12)  is  used  to  add,  delete,  or  edit  the  DIRS  (treat¬ 
ment)  code  file.  Deleting  means  erasing  of  an  existing  code 
in  the  file.  Editing  means  changing  an  existing  code.  When 
calling  these  functions,  the  procedure  is  similar  to  that  of 
data  entry  described  in  the  DIRS  entry  section. 
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Figure  3.12  Update  DIRS  Codes  Menu 


c.  Update  Provider  Codes  Menu 

The  function  of  the  Update  Provider  Codes  menu 
(Figure  3.13)  is  similar  to  that  described  above  for  Change 
DIRS  Codes.  In  this  instance,  rather  than  treatment  codes, 
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Figure  3.13  Update  Provider  Codes  Menu 
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update  function  and  display  function  pertains  to  the  treatment 
provider  at  a  given  command, 
d.  Report  Menu 

Branch  clinic  report  menu  (Figure  3.14)  presents 
users  with  a  number  of  options  related  to  reporting  of  DIRS 
data  by  various  chronological  periods.  Using  the  options 
available  in  this  menu,  the  current  total  of  treatments, 
treatments  by  provider,  by  command,  etc.,  may  be  obtained. 
Additionally,  a  Major  Treatment  Report  option  is  available  as 
a  menu  selection  for  internal  reporting  purposes.  Examples 
of  each  report  selection  are  provided  in  Appendix  H. 
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DAILY  REPORT 
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Figure  3.14  Branch  Clinic  Report  Menu 


e.  File  Utilities  Menu 


Menu  screen  in  Figure  3.15  offers  system  users  the 
ability  to  reindex,  backup,  transfer,  and  start  a  new 
recording  year  all  from  within  the  DIRS  application. 
Providing  these  necessary  functions  from  within  the  system  as 
menu-driven  options  helps  simplify  the  normally  onerous  and 
often  neglected  tasks  such  as  backing  up  system  data. 

The  reindex  data  files  option  should  be  selected 
when  the  system  shows  signs  of  incorrect  operation  such  as 
incorrectly  assigned  totals  or  data.  As  an  example,  reports 
may  display  zero  work  for  all  providers  at  a  specified  command 
for  a  given  month.  If  this  information  is  incorrect,  using 
the  reindex  option  will  reassign  the  appropriate  key  field  to 
their  respective  records.  The  reindex  feature  is  often 
required  in  any  database  system.  Power  surges,  improper  file 
closing  and  hardware  malfunctions  are  examples  of  possible 
causal  factors  for  index  distortion.  The  reindex  option  is 
provided  to  reestablish  the  proper  links  and  pointers  to 
correct  the  potential  damage  caused  by  these  malfunctions. 
Simplicity  inherent  in  the  menu  interaction  format,  should 
help  increase  the  frequency  of  back-ups  and  maintenance  of 
application  data. 

The  "Start  New  Year"  option  is  provided  when  the 
users  wish  to  begin  recordkeeping  functions  for  a  new 
reporting  year;  either  calendar,  fiscal  or  other  arbitrary 
selection.  Failure  to  select  this  option  when  starting  a  new 
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Figure  3.15  File  Utilities  Menu 

reporting  period  will  result  in  overwritten  data  values  and 
incorrect  totals  for  the  selected  period. 

The  "Transfer  Data  to  Disk"  option  is  selected  to 
transfer  data  for  a  monthly  reporting  period  to  a  "floppy 
disk"  for  subsequent  export  to  the  appropriate  Headquarters 
command.  Production  of  the  OCR  report  form  may  only  be 
accomplished  at  the  Headquarters  level  after  import  of  the 
transfer  files. 

Selection  of  transfer  routine  will  transfer  the 
working  file  to  a  floppy  disk.  The  UIC  window  located  in  the 
lower  right  corner  depicted  in  Figure  3.16  prompts  the  user 
to  select  a  number;  1  through  5.  The  number  "5"  is 
representative  of  a  Headquarters  command  with  five  subordinate 
DTFs .  This  number  will  reflect  the  actual  number  of  DTFs 
supporting  as  few  as  one  or  as  many  as  nine.  If  the  system 
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Figure  3.16  Transfer  Data  to  Disk  Screen 


is  being  used  at  a  branch  clinic,  only  one  UIC  is  displayed 
and  selected.  User  input  of  the  correct  UIC  is  critical, 
because  a  UIC  FIELD  will  be  appended  on  the  TRANS.  FILE  based 
on  the  UIC  input.  The  TRANS.  FILE  is  the  database  export  file 
to  be  received  by  the  corresponding  Headquarters  command. 
This  routine  will  be  selected  when  a  subordinate  DTF  is 
required  to  submit  data  to  headquarters.  Regardless  of 
transmission  medium,  the  export  routine  must  be  selected  to 
transfer  all  data  to  floppy  disk,  prior  to  submission  of  the 
updated  monthly  data  requirements.  The  export  procedure 
described  above  provides  a  necessary  if  subtle  control 
mechanism  ensuring  that  data  back-ups  are  performed  at  least 
once  a  month.  When  properly  labeled  with  the  appropriate  UIC, 
and  month  of  transfer,  the  floppy  disks  containing  the  TRANS 
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database  file  (dbf)  provide  a  convenient  source  of  back-up 
data.  The  menu  status  box  (part  C)  will  provide  a  prompt  to 
insert  a  floppy  disk  into  the  appropriate  drive,  and  a  message 
indicating  the  number  of  records  transferred, 
f.  Headquarters  Menu 

Headquarters  menu  (Figure  3.17)  is  intended  for  a 
Headquarters  command  to  facilitate  transfer  of  DIRS  data  from 
subordinate  dental  commands,  and  the  obligatory  submission  of 
DIRS  reports.  To  that  end,  file  import/export  facilities  are 
provided  as  menu  options  for  operation  from  within  the  DIRS 
application. 
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Figure  3.17  Headquarter's  Menu 


"IMPORT  FILES"  option  is  provided  to  receive  files 
transmitted  from  subordinate  commands.  Similarly,  the  "EXPORT 
FILES"  option  is  provided  to  allow  a  Headquarters  command  to 
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send  a  pre-selected  month  of  data  for  all  of  its  subordinate 
commands.  Selection  of  the  "DO  REPORTS"  option  will  result  in 
the  display  of  the  screen  presented  in  Figure  3 . 18  with 
provisions  for  selection  of  either  the  DIRS  OCR  format  monthly 
report  or  a  "PROVIDERS  STATS"  internal  report  option. 
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Figure  3 . 18  Headquarters  Report  Menu 

The  "MONTHLY  DIRS  REPORT"  selection  option  is 
supported  by  the  menu  screen  presented  in  Figure  3.19.  This 
selection  will  enable  Headquarters  to  print  the  standard 
monthly  NAVMED  6600/8  OCR  form  required  for  submission  of  DIRS 
data  to  COMN AVME DCOM  using  an  OCR  font  capable  printer. 

The  Provider  Stats  option  at  Headquarters  level  is 
a  compilation  of  all  subordinate  DTF's  Provider  Stats  reports, 
an  example  of  the  Provider  Stats  Report  is  provided  in 
Appendix  H. 
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Figure  3.19  HQ  OCR  DIRS  SCREEN 

The  "START  NEW  YEAR  (HQ  ONLY)”  option  provided  on 
the  Headquarters  menu  is  identical  in  function  to  that 
provided  by  the  "START  NEW  YEAR"  option  for  subordinate  DTFs 
except  that  it  only  reinitializes  the  Stats  database.  As 
previously  discussed,  this  option  is  used  to  initialize 
records  to  zero,  providing  recordkeeping  functions  for  a  new 
reporting  year;  either  calendar,  fiscal  or  other  arbitrary 
selection . 
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IV.  SYSTEM  IMPLEMENTATION 


A.  INTRODUCTION 

The  final  step  in  systems  analysis  is  system 
implementation.  At  this  step,  the  chief  objective  is  in 
building  the  system  physical  design  which  provides  precise 
functionality  users  desire,  and  most  closely  mirrors  logical 
design  specifications.  It  is  in  this  step  that  the  components 
of  database  design,  relations,  rows  and  attributes,  are 
translated  into  DBMS-specific  tables,  records  and  fields. 

The  DBMS  selected  for  use  in  this  task  is  dBASE  III  PLUS, 
a  product  of  Ashton-Tate.  The  specifics  of  both  dBASE  III 
PLUS,  and  QUICKSILVER,  the  compiler  program  used,  will  be 
addressed  following  a  discussion  of  methods  used  to  generate 
database  tables  and  screens. 

1 •  Tables 

During  user  requirements  phase,  application  data 
requirements  were  identified  and  were  presented  as  objects. 
These  objects  were  then  translated  into  relations  in  the 
logical  design  phase.  In  the  implementation  phase,  these 
relations  are  translated  into  DBMS-specific  (in  this 
application,  dBASE  III  PLUS)  tables.  "The  order  of  fields 
within  a  record  is  the  same  for  every  record  in  the  file,  and 
is  called  the  file  structure."  [Ref.  4]  This  file  structure 
is  designed  to  support  specifics  of  individual  DBMSs  by 
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establishing  the  order,  length,  number  of  fields  and  data  type 
in  each  record. 

2 .  Screen  Design 

During  user  requirements  phase,  the  second  task  was  to 
fully  specify  system  functional  requirements.  The  established 
methodology  to  most  easily  describe  the  requirements  is 
through  the  use  of  dataflow  diagrams  (DFD) .  A  dataflow 
diagram  is  "a  chart  used  by  systems  analysts  to  illustrate 
business  functions  and  their  data  interfaces.  Sometimes 
called  a  bubble  chart."  [Ref.  3]  During  logical  design  phase 
DFDs  were  converted  into  menus.  Use  of  these  menus  serves  as 
a  control  mechanism  to  prevent  update  anomalies  during  file 
maintenance  operations  (insertions,  deletions,  and 
modifications) .  In  the  implementation  phase  menus  are 
translated,  providing  a  mechanism  to  manipulate  data  through 
screens  or  views,  which  are  materializations  of  objects.  An 
object  is  a  specific  instance  or  representation  of  one 
particular  entity  such  as  a  provider  or  a  treatment.  It  is 
important  to  note  that  "entities  are  perceptions  and  may  or 
may  not  be  physical."  [Ref.  3]  This  distinction  is  important 
because  a  screen  or  view  may  represent  rows  and  columns  from 
a  single  table,  several  tables,  or  may  form  a  separate  and 
distinct  depiction  (view)  not  associated  with  a  physical  table 
or  tables.  This  virtual  table  is  defined  by  the  user's  view. 
An  example  of  each  screen  used  to  develop  the  application  is 
located  in  Appendix  K. 
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B.  dBASE  III  PLUS 


The  dBASE  series  is  by  far  the  dominant  data  management 
software  for  the  IBM  PC. .. .Beginning  with  the  introduction 
of  dBASE  II  in  January  1981  (before  the  announcement  of  the 
PC),  and  continuing  with  dBASE  III  in  1984,  dBASE  III  PLUS 
in  1986,  and  dBASE  IV  in  1988,  Ashton-Tate  has  remained  the 
unquestioned  market  leader.  [Ref.  5] 

Though  potentially  more  powerful  Standard  Query  Language 
(SQL) -based  relational  database  management  systems  are 
commercially  available,  dBASE  III  Plus  was  selected  for  use 
in  developing  this  application.  There  are  numerous  reasons 
for  selection  of  this  particular  product,  among  them;  the 
established  reputation  of  the  product  as  one  of  the  industry 
standard  programming  languages  for  developing  applications 
software  on  microcomputers,  availability  of  after-market 
compiler  and  debugger  software  for  the  DBMS,  user  and 
programmer  familiarity  with  the  product,  and  program 
availability  within  many  Navy  commands.  An  important  user- 
defined  goal  for  application  development  effort  is  related  to 
hardware  and  system  requirements  imposed  on  the  user.  As 
described  in  Chapter  I,  developer  goals  to  satisfy  user 
requirements  included  an  imbedded  DBMS  in  a  compiled  DIRS 
application  capable  of  use  on  existing  hardware  (in  the  case 
of  the  U.S.  Navy  dental  community,  an  IBM-compatible  system 
with  a  minimum  2  0  megabyte  hard  disk)  .  A  product  of  this 
nature  would  not  require  additional  off-the-shelf  database 
software  purchases. 

dBASE  III  PLUS  includes  a  wide  range  of  application 
development  tools  and  supports  three  basic  user  interaction 
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modes:  assist,  interactive,  and  programming  language.  [Ref. 

6] 

The  bulk  of  application  development  work  on  this  project 
was  performed  using  dBASE  III  PLUS  as  a  programming  language. 
In  this  capacity,  maximum  flexibility  for  custom  development 
is  facilitated.  The  software  development  cycle  followed  by 
the  dBASE  programmer  as  defined  in  [Ref.  6:p.  35],  is: 

Problem  definition. 

Database  design. 

Modular  program  design. 

Coding. 

Testing,  debugging,  and  enhancing. 

The  similarity  to  the  overall  application  development 
cycle  is  apparent,  with  emphasis  on  detailed  requirements 
analysis  prior  to  coding  through  structured  programming  and 
top-down  design.  Critical  to  goal  attainment  of  reduced 
software  purchases,  use  on  existing  hardware,  and  streamlined 
user  training,  is  availability  of  after-market  DBMS-specific 
program  compilers.  Not  all  DBMS  products  possess  the  facility 
within  the  program  to  compile  developed  code  for  conversion 
into  DOS-executable  .exe  files  capable  of  operation 
independent  of  the  DBMS  software.  A  significant  market 
introduction  delay  for  compiler  programs  exists  for  even  the 
most  commercially  successful  DBMS.  Programmer  familiarity  and 
availability  of  Quicksilver  a  WordTech  Systems,  Inc.  product, 
resulted  in  its  selection  as  the  compiler  used  in  developing 
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this  application,  though  other  packages  such  as  Clipper,  a 
product  of  Nantucket,  Inc.,  are  available. 

The  Quicksilver  compiler  supports  most  dBASE  III  PLUS 

functions,  and  provides  additional  user  defined  functions  such 

as  specification  of  programs  and  files  in  separate  drives  or 

directories,  networking  commands,  file-sharing  capabilities, 

facilities  for  developing  windows  for  pop-up  menus  and  help 

screens,  and  support  for  environmental  variables.  An 

additional  benefit  derived  from  compiled  applications  is 

increased  program  execution  speed  for  processes  not  "heavily 

disk  bound"  or  requiring  access  to  peripherals  such  as  screens 

or  printers.  Each  time  a  disk  or  external  device  must  be 

accessed,  program  execution  is  slowed. 

Compiling  a  custom  system  does  not  guarantee  that  the  entire 
system  is  suddenly  going  to  run  at  the  speed  of  light.  Keep 
in  mind  that  a  compiler  basically  just  preinterprets  your 
command  files  and  stores  these  already  interpreted  commands 
in  a  separate  file.  It  does  not  make  the  hardware  operate 
any  faster.  [Ref.  6:p.  817] 

While  dramatic  speed  improvements  are  indeed  possible,  they 
are  subject  to  the  limitations  described  above.  A  further 
advantage  of  Quicksilver  is  the  optional  linker,  allowing 
users  to  specify  "the  type  of  machine  the  compiled  program 
will  be  run  on"  [Ref.  5],  such  as  IBM  PCs,  100%-compatibles , 
and  MS-DOS  machines. 
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C .  SOFTWARE  DOCUMENTATION 


1 .  User  Manual 

Provisions  for  a  detailed  user  manual  are  made  in 
Appendix  K.  Written  with  a  user  perspective,  including 
limited  system  development  background,  the  user  manual  is 
intended  to  support  users  with  varying  computer  application 
experience  by  providing  detailed  menu  and  screen  format 
examples.  A  menu  hierarchy  is  provided  and  followed  to 
describe  the  user  options  available.  Each  figure  depicted  in 
the  manual  is  accompanied  by  related  text  describing  the  menu 
options,  selection  consequence,  escape  procedures  and  any 
special-purpose  or  function  key  operation.  No  previous  user 
familiarity  with  either  dBASE  III  PLUS  or  Quicksilver  is 
necessary  or  assumed. 

2 •  Program  Code 

As  previously  described,  all  required  program  coding 
was  written  using  the  programming  language  function  of  dBASE 
III  PLUS.  The  length  of  the  program  code  (141  pages) 
precludes  its  incorporation  as  an  appendix.  However,  in  order 
to  enable  easier  end-user  maintenance,  jource  code  will  be 
submitted  in  hard-copy  under  separate  correspondence,  and  on 
floppy  disk  with  the  complete  DIRS  program  for  delivery  to  end 
users . 

D.  REPORTS 

System  users  have  a  number  of  reporting  options  for  both 
internal  management  and  DOD-mandated  submissions.  Among  the 
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available  options  for  branch  clinics  are:  daily,  monthly  and 
annual  reports,  provider  statistics  (stats) ,  and  major 
treatment  reports.  At  Headquarter's  level,  in  addition  to  the 
receipt  of  reports  from  respective  subordinate  clinics, 
cumulative  provider  stats  and  the  monthly  DIRS  report  are 
available  as  reporting  options.  An  example  of  each  report  is 
presented  in  Appendix  H. 


V.  CONCLUSIONS  AND  RECOMMENDATIONS 


A.  SUMMARY  AND  CONCLUSIONS 

The  frequency  and  volume  of  treatment  data  collected  and 
stored  by  various  Dental  Treatment  Facilities  severely  taxes 
manual  data  handling  and  report  generating  capabilities  of  the 
limited  administrative  staff  at  each  facility.  Critical  to 
the  success  of  the  application  is  increasing  the  speed  and 
accuracy  of  data  input,  thereby  enhancing  effectiveness  and 
productivity  of  the  unit,  without  imposing  additional  hardware 
requirements  or  burdening  users  with  complex,  lengthy  software 
training  procedures. 

The  DIRS  system  developed  in  the  course  of  this  thesis  not 
only  facilitates  data  entry  procedures  and  monthly  preparation 
of  DOD-directed  reports,  but  also  supports  data  import/export 
functions  from  subordinate  DTFs  to  a  Headquarters  command. 
Personnel  management  and  reporting  procedures  are  provided  to 
support  internal  management  at  either  subordinate  DTF  or 
Headquarters  level. 

As  discussed  in  the  previous  chapter,  dBASE  III  PLUS  was 
selected  to  develop  the  DIRS  application.  By  compiling  the 
resulting  source  code  through  the  use  of  Quicksilver,  users 
need  not  be  familiar  with  dBASE  to  understand  and  use  the  DIRS 
program.  While  "user  friendliness"  is  a  desirable  attribute 
of  any  system,  it  is  often  an  ill-defined  and  elusive  goal. 
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In  this  application,  emphasis  on  extensive  menus  and  selection 
keys  function  as  control  mechanisms  help  guide  the  user 
through  the  system.  Crucial  to  user  acceptance,  extensive 
documentation  and  supporting  diagrams  are  provided  in  the 
User's  Manual  found  in  Appendix  K.  Additional  "hands-on” 
experience  should  provide  the  remaining  system  training 
requirements . 

B.  RECOMMENDATIONS  AND  FUTURE  WORK 

The  process  of  developing  this  application  provided 
numerous  "case-study"  examples  of  the  importance  of  correctly 
defining  user  requirements  prior  to  initializing  development 
work.  The  process  was  facilitated  by  knowledgeable  users  with 
generally  well-defined  and  reasonably  consistent  structured 
data  flows.  Geographical  distance  between  users  and 
developers  posed  some  difficulties,  so  phone  conversations, 
mailings  and  personal  visits  to  NAVDENCLINIC,  Long  Beach,  Ca. , 
and  Director  of  Dental  Services,  San  Diego,  Ca.,  were  crucial 
to  an  effective  requirements  definition  process  and  user 
familiarization  training.  Developing  and  mailing  an  early 
prototype  of  DIRS  to  both  user  sites  provided  an  exceptionally 
valuable  mechanism  to  not  only  further  clarify  requirements, 
but  also  identify  several  previously  overlooked  program 
anomalies.  Evolving  user  requirements  and  subsequent 
identification  of  additional  features  and  modules  for  addition 
to  future  versions  of  the  DIRS  application  developed  in  the 
scope  of  this  thesis,  provide  opportunities  for  program 
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expansion  either  internally  or  within  the  scope  of 
proposed  DENMIS  system. 


the 
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YEAR 


MONTHLY 


COMMAND 

MONTHLY 

MV 

Tot  Yr.  BCat  01 
Tot  Yr.  BCat  02 
Tot  Yr.  BCat  06 
Tot  Yr.  BCat  08 
Tot  Yr.  BCat  08 
Tot  Yr.  BCat  10 
Tot  Yr.  BCat  11 
Tot  Yr.  BCat  12 
Tot  Yr.  BCat  13 


DAILY 


PROVIDER 


I  TREATMENT 
Date 

Tot  Dly.  BCat  01 
Tot  Dly.  BCat  02 
Tot  Dly.  BCat  05 
Tot  Dly.  BCat  08 
Tot  Dly.  BCat  08 
Tot  Dly.  BCat  10 
Tot  Dly.  BCat  11 
Tot  Dly  BCat  12 
Tot  Dly.  BCat  13 


COMMAND 

DAILY 

MV 

Month 

Tot  Mon.  BCat  01 
Tot  Mon.  BCat  02 
Tot  Mon.  BCat  06 
Tot  Mon.  BCat  08 
Tot  Mon.  BCat  08 
Tot  Mon.  BCat  10 
Tot  Mon.  BCat  11 
Tot  Mon.  BCat  12 
Tot  Mon.  BCat  13 


BENEFICIARY  CODES: 


01  *  Active  Duty,  U.S.  Navy 

02  -  Active  Duty,  U.S.  Marine  Corps 

05  -  Active  Duty,  Other  Services 

08  -  Recruit,  U.S.  Navy  or  Marine  Corps 

09  -  Dependents  of  Active  Duty 

U.S.  Uniformed  Services  Personnel 

10  -  Dependents  of  Retired  or  Deoeseed 

U.S.  Uniformed  Services  Personnel 

11  -  Retired  Uniformed  Servioee  Personne 

12  -  Other  Personnel  not  listed  in  Codes 

01  through  11  and  13 

13  -  Dependent  Children, 

(17  &  under  and  unmarried) 
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APPENDIX  B 


OBJECT  DEFINITIONS 


STATS  (HQ)  OBJECT 

Descriptive  Name _ Domain  Name 

Unit  Identification  Code  Clinic 

COMMAND:  COMMAND  object;  MV 


COMMAND  OBJECT 


Descriptive  Name 


Domain  Name 


Unit  Identification  Code 
Command  Name 
MEPERS  Work  Center  Code 
PROVIDER:  PROVIDER  object; 

YEAR:  YEAR  object; 


Clinic 

Command 

UCAcode 

MV 

MV 


PROVIDER  OBJECT 
Descriptive  Name _ 


Domain  Name 


Provider  Code 
First  Name 
Last  Name 
Military  Rank 
Duty  Status 

DAILY:  DAILY  object; 


Code 

Fname 

Lname 

Rank 

Reserve 

MV 


TREATMENT 
(DIRS  CODE)  OBJECT 

Descriptive  Name _ Domain  Name 


DIRS  Code  Dirs 

Description  Descript 

Comp  Value  (time)  Weight 

DAIT.vr  DAILY  object;  MV 
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YEAR  OBJECT 


Descriptive  Name _ Domain  Name 

Year  Total  to  date  for 

Beneficiary  Category  01  Tot  Yr.  BCat  01 

Year  Total  to  date  for 

Beneficiary  Category  02  Tot  Yr.  BCat  02 

Year  Total  to  date  for 

Beneficiary  Category  05  Tot  Yr.  BCat  05 

Year  Total  to  date  for 

Beneficiary  Category  08  Tot  Yr.  BCat  08 

Year  Total  to  date  for 

Beneficiary  Category  09  Tot  Yr.  BCat  09 

Year  Total  to  date  for 

Beneficiary  Category  10  Tot  Yr.  BCat  10 

Year  Total  to  date  for 

Beneficiary  Category  11  Tot  Yr.  BCat  11 

Year  Total  to  date  for 

Beneficiary  Category  12  Tot  Yr.  BCat  12 

COMMAND:  COMMAND  object 

MONTHLY:  MONTHLY  object;  MV 


MONTHLY  OBJECT 

Descriptive  Name _ Domain  Name 

Month  Total  to  date  for 

Beneficiary  Category  01  Tot  Mon.  BCat  01 

Month  Total  to  date  for 

Beneficiary  Category  02  Tot  Mon.  BCat  02 

Month  Total  to  date  for 

Beneficiary  Category  05  Tot  Mon.  BCat  05 

Month  Total  to  date  for 

Beneficiary  Category  08  Tot  Mon.  BCat  08 

Month  Total  to  date  for 

Beneficiary  Category  09  Tot  Mon.  BCat  09 

Month  Total  to  date  for 

Beneficiary  Category  10  Tot  Mon.  BCat  10 

Month  Total  to  date  for 

Beneficiary  Category  11  Tot  Mon.  BCat  11 

Month  Total  to  date  for 

Beneficiary  Category  12  Tot  Mon.  BCat  12 

COMMAND:  COMMAND  object? 

DAILY:  DAILY  object;  MV 


69 


DAILY  OBJECT 


Descriptive  Name - - - 

Daily  Total  for 
Beneficiary  Category  01 
Daily  Total  for 
Beneficiary  Category  02 
Daily  Total  for 
Beneficiary  Category  05 
Daily  Total  for 
Beneficiary  Category  08 
Daily  Total  for 
Beneficiary  Category  09 
Daily  Total  for 
Beneficiary  Category  10 
Daily  Total  for 
Beneficiary  Category  ll 
Daily  Total  for 
Beneficiary  Category  12 
PROVIDER:  PROVIDER 

TREATMENT :  TREATMENT 


Domain  Name 

Tot  Dly.  BCat  01 
Tot  Dly.  BCat  02 
Tot  Dly.  BCat  05 
Tot  Dly.  BCat  08 
Tot  Dly.  BCat  09 
Tot  Dly.  BCat  10 
Tot  Dly.  BCat  11 
Tot  Dly.  BCat  12 

ob j ect 
object 
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APPENDIX  C 


CLINIC: 

COMMAND: 

UCA_Code : 

PROVCODE : 

FNAME : 

LNAME : 

RANK: 

RESERVE : 


DOMAIN  DEFINITIONS 


Number (5) 

This  number  represents  the  unique  5-digit  Unit 
Identification  Code  (UIC)  assigned  to  every 
military  command.  Each  DTF  has  an  individually 
assigned  UIC,  which  is  required  on  all 
forms  submitted. 

Character (40) 

The  full  DTF  name  as  listed  in  the  NAVMEDCOMINST 
6600. IB,  Chapter  III. 

Character (4) 

The  4-digit  MEPERS  (UCA)  code  for  each  work 
center.  The  first  three  digits  distinguish 
between  dental  clinical  or  laboratory  procedures, 
while  the  fourth  digit  represents  the  location 
(work  center)  where  the  procedure  was  performed. 

Character (3) 

The  provider  code  is  a  three-digit  code  assigned 
to  uniquely  represent  a  dental  provider  at  a 
given  DTF. 

Character (20) 

Dental  provider's  first  name. 

Character (20) 

Dental  provider's  last  name. 

Character ( 4 ) 

Dental  provider's  military  or  civilian  rank, 
i . e . ;  CAPT . 

Character (1) 

Dental  provider's  status.  Three  values  can  be 
inserted  here.  "C"  for  civilian  contractor,  "R" 
for  reservist  performing  two  weeks  active  duty, 
or  "0"  for  other.  "O"  shall  be  the  default 
value . 
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DIRS: 


DESCRIPT: 

WEIGHT: 


TOTi : 


TOT  2  : 


TOT  5: 


TOT8 : 


TOT9  : 


TOTIO : 


TOTH: 


Character (4) ,  range:  0001  to  9999. 

Actual  command  treatment  code.  Although 
specified  as  a  character  field,  a  built-in 
control  mechanism  allows  only  numeric  values  to 
be  entered.  The  DIRS  code  identifies  a  specific 
treatment. 

Character ( 15) 

Short  description  (name)  of  a  DIRS  code. 
Number(4),  Picture  999.9 

Each  DIRS  code  as  a  composite  factor  (weight) 
associated  with  it.  This  weight  is  used  for 
computing  total  time  spent  per  a  requested  time 
frame  for  a  particular  treatment. 

Number(7),  picture  9999.99 

The  sum  of  all  category  one  beneficiary  code  for 
a  specific  treatment  and  specific  provider  for 
the  year  multiplied  by  its  associated  weight. 

Number (7 ) ,  pic€ure  9999.99 

The  sum  of  all  category  two  beneficiary  code  for 
a  specific  treatment  and  specific  provider  for 
the  year  multiplied  by  its  associated  weight. 

Number (7) ,  picture  9999.99 

The  sum  of  all  category  five  beneficiary  code  for 
a  specific  treatment  and  specific  provider  for 
the  year  multiplied  by  its  associated  weight. 

Number (7 ) ,  picture  9999.99 

The  sum  of  all  category  eight  beneficiary  code 
for  a  specific  treatment  and  specific  provider 
for  the  year  multiplied  by  its  associated  weight. 

Number (7) ,  picture  9999.99 

The  sum  of  all  category  nine  beneficiary  code  for 
a  specific  treatment  and  specific  provider  for 
the  year  multiplied  by  its  associated  weight. 

Number(7),  picture  9999.99 

The  sum  of  all  category  ten  beneficiary  code  for 
a  specific  treatment  and  specific  provider  for 
the  year  multiplied  by  its  associated  weight. 

Number (7) ,  picture  9999.99 

The  sum  of  all  category  eleven  beneficiary  code 
for  a  specific  treatment  and  specific  provider 
for  the  year  multiplied  by  its  associated  weight. 
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TOT 12 : 


TOT13 : 


M  totl : 


M  tot 2 : 


M  tot5 : 


M  tots: 


M  tot9 : 


M  totlO : 


M  totll: 


Number (7),  picture  9999.99 

The  sum  of  all  category  twelve  beneficiary  code 
for  a  specific  treatment  and  specific  provider 
for  the  year  multiplied  by  its  associated  weight. 

Number (7),  picture  9999.99 

The  sum  of  all  category  thirteen  beneficiary  code 
for  a  specific  treatment  and  specific  provider 
for  the  year  multiplied  by  its  associated  weight. 

Number(5) ,  Picture  99999 

Total  number  of  treatment  provided  for  a  specific 
treatment  by  a  specific  provider  for  beneficiary 
code  1.  A  cumulative  count  of  Dtotl  domain  for 
the  user's  open  month  selection. 

Number (5) ,  Picture  99999 

Total  number  of  treatment  provided  for  a  specific 
treatment  by  a  specific  provider  for  beneficiary 
code  2.  A  cumulative  count  of  D_tot2  domain  for 
the  user's  open  month  selection. 

Number(5) ,  Picture  99999 

Total  number  of  treatment  provided  for  a  specific 
treatment  by  a  specific  provider  for  beneficiary 
code  5.  A  cumulative  count  of  D_tot5  domain  for 
the  user's  open  month  selection. 

Number (5) ,  Picture  99999 

Total  number  of  treatment  provided  for  a  specific 
treatment  by  a  specific  provider  for  beneficiary 
code  8.  A  cumulative  count  of  D_tot8  domain  for 
the  user's  open  month  selection. 

Number(5) ,  Picture  99999 

Total  number  of  treatment  provided  for  a  specific 
treatment  by  a  specific  provider  for  beneficiary 
code  9.  A  cumulative  count  of  D_tot9  domain  for 
the  user's  open  month  selection. 

Number(5) ,  Picture  99999 

Total  number  of  treatment  provided  for  a  specific 
treatment  by  a  specific  provider  for  beneficiary 
code  10.  A  cumulative  count  of  D_totl0  domain 
for  the  user's  open  month  selection. 

Number(5),  Picture  99999 

Total  number  of  treatment  provided  for  a  specific 
treatment  by  a  specific  provider  for  beneficiary 
code  11.  A  cumulative  count  of  D_totll  domain 
for  the  user's  open  month  selection. 
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M  totl2 : 


M  totl3 : 


D  T0T1 : 


D  TOT2 : 


D  TOT5 : 


D  TOT8 : 


D  TOT9: 


D  TOTIO : 


D  TOT 11: 


D  TOT 12 : 


Number(5) ,  Picture  99999 

Total  number  of  treatment  provided  for  a  specific 
treatment  by  a  specific  provider  for  beneficiary 
code  12 .  A  cumulative  count  of  D_totl2  domain 
for  the  user's  open  month  selection. 

Number (5) ,  Picture  99999 

Total  number  of  treatment  provided  for  a  specific 
treatment  by  a  specific  provider  for  beneficiary 
code  13.  A  cumulative  count  of  D_totl3  domain 
for  the  user's  open  month  selection. 

Number(5) ,  Picture  99999 

Total  number  .of  treatment  provided  for  a  specific 
treatment  by  a  specific  provider  for  beneficiary 
cods  1. 

Number(5)f  Picture  99999 

Total  number  of  treatment  provided  for  a  specific 
treatment  by  a  specific  provider  for  beneficiary 
code  2 . 

Number(5),  Picture  99999 

Total  number  of  treatment  provided  for  a  specific 
treatment  by  a  specific  provider  for  beneficiary 
code  5. 

Number (5),  Picture  99999 

Total  number  of  treatment  provided  for  a  specific 
treatment  by  a  specific  provider  for  beneficiary 
code  8 . 

Number (5) ,  Picture  99999 

Total  number  of  treatment  provided  for  a  specific 
treatment  by  a  specific  provider  for  beneficiary 
code  9 . 

Number(5),  Picture  99999 

Total  number  of  treatment  provided  for  a  specific 
treatment  by  a  specific  provider  for  beneficiary 
code  10. 

Number(5) ,  Picture  99999 

Total  number  of  treatment  provided  for  a  specific 
treatment  by  a  specific  provider  for  beneficiary 
code  11. 

Number (5) ,  Picture  99999 

Total  number  of  treatment  provided  for  a  specific 
treatment  by  a  specific  provider  for  beneficiary 
code  12. 
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D  T0T13 : 


Number (5) ,  Picture  99999 

Total  number  of  treatment  provided  for  * 

cole  ??nt  by  3  Sf>eClflc  Provider  for  bene?iCLry° 
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APPENDIX  D 
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APPENDIX  E 


UPDATE,  DISPLAY  AND  CONTROL  MECHANISMS 


PROVIDER  OBJECT 
Update  Mechanisms 


I .  Create  PROVIDER 

A.  Input  Description 

Provider  code  assigned  by  database  administrator 
Provider  name  (last  and  first  name) 

Rank  or  rate 

Status  code  (R  =  reservist,  C  =  contracted 
personnel , 

O  =  others  that  are  not  R  or  C) 

B.  Output  Description 

-  New  PROVIDER  object 

C.  Processing  Notes 

System  shall  check  to  ensure  that  no  two 
providers  have  the  same  provider  code 

D.  Volume 

Approximately  six  to  ten  providers  per  dental 
clinic 

Volume  is  dependent  on  the  size  of  command 

E.  Frequency 

Created  when  a  new  provider  checks  onboard 


II.  Modify  PROVIDER 

A.  Input  Description 

Correction  to  provider  listing 

-  PROVIDER  object 

B.  Output  Description 

-  Modified  PROVIDER  object 

Confirmation  message  while  updating  on  screen 

C.  Processing  Notes 

System  shall  not  allow  user  to  modify  key  field 
(provider  code) 
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D.  Volume 

One  record  correction  per  quarter 

E .  Frequency 

One  record  correction  per  quarter 


III.  Delete  PROVIDER 

A.  Input  Description 

Transferred  personnel  report 
-  PROVIDER  object 

B.  Output  Description 

updated  PROVIDER  object 

Confirmation  message  to  delete  record  on  screen 

C.  Processing  Notes 

Record  is  displayed  for  confirmation.  User  must 
respond  affirmatively  to  the  prompt  to  delete 
record 


D. 

Volume 

Varies 

with 

the 

number 

of 

transfers 

E. 

Frequency 

Varies 

with 

the 

number 

of 

transfers 

PROVIDER  OBJECT 
Display  Mechanisms 


I.  PROVIDER  listing 

A.  Output  Description 

Form  showing  provider  code,  first  and  last  name, 
rank  and  status  code  (R,  C,  0) 

B.  Source  data 

PROVIDER  object 

C.  Processing  Notes 

Produce  weekly  by  database  administrator 

D.  Volume 

One  report  per  week 

E.  Frequency 

One  report  per  week 
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PROVIDER  OBJECT 
Control  Mechanisms 


I.  Pop-up  windows,  system  validation  routines,  along  with 
user  prompts 


TREATMENT  OBJECT 
Update  Mechanisms 


I .  Create  TREATMENT 

A.  Input  Description 

DIRS  treatment  codes,  description,  and  Critical 
Time  Value  (CTV)  are  specified  in  NAVMEDCOMINST 
6600. IB 

New  code  created  by  Bureau  of  Medicine  (BUDMED) 

B.  Output  Description 

New  TREATMENT  object 

C.  Processing  Notes 

System  shall  ensure  that  each  treatment  code  is 
unique 

-  This  table  will  be  created  for  the  user 

D.  Volume 

Approximately  three  hundred  codes 

E .  Frequency 

Once  at  system  development 


II.  Modify  TREATMENT 

A.  Input  Description 

Correction  to  initial  entries  made  during  system 
implementation 

-  Changes  made  to  NAVMEDCOMINST  6600. IB 

B.  Output  Description 

Modified  TREATMENT  object 

Confirmation  message  while  updating  on  screen 

C.  Processing  Notes 

System  shall  not  allow  user  to  modify  key  field 
(treatment  code) 

D.  Volume 

Extremely  low 
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E .  Frequency 

-  Approximately  once  every  two  years  some  of  the 
treatment  codes  may  change  or  its  CTV  will 
change.  These  changes  are  determined  at  an 
echelon  2  command  level  not  at  an  echelon  3  or  4 
command  where  this  system  is  designed  for  use 


III.  Delete  TREATMENT 

A.  Input  Description 

Invalid  treatment  code  entered  during  creation 
Outdated  treatment  codes  that  have  been  deleted 
in  NAVMEDCOMINST  6600. IB 

B.  Output  Description 

Updated  TREATMENT  object 

Confirmation  message  while  updating  on  screen 

C.  Processing  Notes 

System  shall  allow  user  verification  to  modify 
key 

Confirmation  message  to  delete  record  on  screen 

D.  Volume 

Extremely  low 

E .  Frequency 

Approximately  once  every  two  year  some  of  the 
treatment  codes  may  change  or  its  CTV  will 
change.  These  changes  are  determined  at  an 
echelon  2  command  level  not  at  an  echelon  3  or  4 
command  where  this  system  is  designed  for  use 


TREATMENT  OBJECT 
Display  Mechanisms 


I.  TREATMENT  listing 

A.  Output  Description 

-  Form  showing  treatment  (DIRS)  code,  description, 
CTV  (weight) 

B.  Source  data 

-  TREATMENT  object 

C.  Processing  Notes 

This  object  is  used  for  treatment  code 
validation  while  updating  the  DAILY,  MONTHLY, 
and  YEARLY  object 
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D.  Volume 

One  report  to  verify  any  updates 

E.  Frequency 

One  per  year 


TREATMENT  OBJECT 
Control  Mechanisms 


I.  Pop-up  windows,  system  validation  routines,  along  with 
user  prompts 


DAILY  OBJECT 
Update  Mechanisms 


I.  Create  Daily 

A.  Input  Description 

Month  selection  (from  menu  selection  options) 
Provider  selection  (from  provider  object) 
Treatment  code  selection  (from  treatment  object) 
-  Manual  data  entry  of  totals  for  each  beneficiary 
(category)  code  treated  (from  daily  providers' 
work  sheet) 

B.  Output  Description 

New  DAILY  object  in  database 
Updated  MONTHLY  object  in  database 
Updated  YEARLY  object  in  database 
Confirmation  message  of  updates  on  screen 
Online  monthly  and  yearly  totals  for  selected 
treatment  and  individual  provider  on  screen 
On  demand  Hardcopy  availability  of  input  data 
for  the  data  entry  session 

C.  Processing  Notes 

The  DAILY  object  is  initialized  with  each 
session,  therefore  the  Daily  report  will  only 
reflect  information  keyed  in  during  the  current 
session 

D.  Volume 

Average  number  of  different  treatments  per 
provider  is  26  treatments  per  day.  Each  clinic 
averages  six  providers  per  work-day  (Monday 
through  Friday) 
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E .  Frequency 

Once  per  day  or  one  per  session  (when  data  is 
entered) .  Users  have  specified  that  data  is 
entered  at  minimum  once  per  week 
Minimum  one  per  week 


II.  Modify  DAILY  data 

A.  Input  Description 

Changes  or  errors  noted  on  daily  providers'  work 
sheet) 

Data  entry  errors  not  corrected  at  initial  entry 
need  to  be  corrected 

Procedure  same  as  with  create  DAILY  except  that 
negative  or  positive  values  are  entered  to 
correctly  adjust  the  monthly  and  yearly  totals 
for  a  requested  provider,  treatment  and  month 

B.  Output  Description 

Modified  DAILY  object  in  database 
Modified  MONTHLY  object  in  database 
Updated  YEARLY  object  in  database 
Confirmation  message  of  updates  on  screen 
Online  monthly  and  yearly  totals  for  selected 
treatment  and  individual  provider  on  screen 
On  demand  Hardcopy  availability  of  input  data 
for  the  modification  data  entry  session 

C.  Processing  Notes 

The  DAILY  object  is  initialized  with  each  new 
data  entry  session,  therefore  the  Daily  report 
will  only  reflect  information  keyed  in  during 
this  session 

D.  Volume 

One  day  per  month,  ten  treatments 

E.  Frequency 

As  needed 

Modification  are  generally  only  needed  due  to 
erroneous  data  entry.  Since  control  mechanisms 
are  built  into  the  system,  prompting  data  entry 
personnel  to  validate  entry  before  entry  is 
accepted  into  the  database,  these  type  of  errors 
are  infrequent 


84 


III.  Delete  DAILY  data 


A.  Input  Description 

Procedure  same  as  with  create  DAILY  except  that 
negative  values  are  entered  to  correctly 
adjust  the  monthly  and  yearly  totals  for  a 
requested  provider,  treatment  and  month 
The  DAILY  object  is  deleted  automatically  when 
the  system  is  executed  for  the  first  time 
during  the  day.  A  new  DAILY  object  reflecting 
the  new  transaction  is  then  generated 

B.  Output  Description 

Modified  DAILY  object  in  database  reflecting 
deleted  transactions 
Updated  MONTHLY  object  in  database 
Updated  YEARLY  object  in  database 
Confirmation  message  of  updates  on  screen 
Online  monthly  and  yearly  totals  for  selected 
treatment  and  individual  provider  on  screen 
On  demand  Hardcopy  availability  of  input  data 
for  the  modification  data  entry  session 

C.  Processing  Notes 

The  DAILY  object  is  initialized  with  each  new 
data  entry  session.  Therefore  the  Daily  report 
will  only  reflect  information  keyed  in  during 
this  session 

D.  Volume 

One  to  tvo  records  per  entry  session 

E.  Frequency 

As  required 


DAILY  OBJECT 
Display  Mechanisms 


I.  Daily  Report 

A.  Output  Description 

Form  showing  by  beneficiary  codes,  and  all 
treatments,  performed  by  each  provider.  The 
report  shall  total  the  number  of  treatments  for 
a  single  treatment  code  with  its  associated 
composite  time  value  total  (CTV) (weighted  time) 
total  number  treatment  performed  times  its  CTV) 
for  all  active  Navy  and  retired  personnel.  The 
form  shall  also  give  a  one-line  summary  of  the 
work  performed  for  each  provider.  A  new  page  is 
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used  for  every  provider.  The  command  daily 
summary  shall  also  be  printed  on  a  separate 
sheet  in  the  same  prestated  format.  See 
Appendix  K  for  an  example  of  the  daily  summary 

B.  Source  data 

DAILY  object 

C.  Processing  Notes 

Daily  object  contains  PROVIDER,  TREATMENT  object 
data 

Use  at  local  command  and  distributed  to  each 
provider  for  accuracy  validation 

D.  Volume 

One  for  entry  clerk 

One  copy  for  each  provider 

One  copy  to  the  administration  officer 

E .  Frequency 

One  daily  or  one  per  data  entry  session 


DAILY  OBJECT 
Control  Mechanisms 


I.  Pull-down  menus,  pop-up  windows,  system  validation 
routines,  along  with  user  prompts 


MONTHLY  OBJECT 
Update  Mechanisms 


I.  Create  Monthly 

A.  Input  Description 

DAILY  object  automatically  updates  the  MONTHLY 
object  for  the  selected  month 

B.  Output  Description 

Updated  MONTHLY  object  in  database 
Updated  YEARLY  object  in  database 
Online  monthly  and  yearly  totals  for  selected 
treatment  and  individual  provider  on  screen 
On  demand  Hardcopy  availability  of  work 
performed  by  provider  for  a  selected  month 

C.  Processing  Notes 

The  DAILY  object  is  initialized  with  each 
new  session.  Therefore  the  Daily  report  will 
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only  reflect  information  keyed  in  during  the 
data  entry  sitting 

D.  Volume 

Average  number  of  different  treatments  per 
provider  is  26  treatments  per  day  times  the 
number  of  work  days  per  month.  Each  clinic 
averages  six  providers  per  work-day  (Monday 
through  Friday) 

E.  Frequency 

Since  DAILY  object  automatically  updates  the 
MONTHLY  object  the  frequency  is  the  same  as  for 
the  DAILY  object  update 
Minimum  one  per  week 


II.  Modify  MONTHLY  data 

A.  Input  Description 

Changes  or  errors  noted  on  daily  providers'  work 
sheet 

Data  entry  errors  not  corrected  at  initial  entry 
need  to  be  corrected 

Procedure  same  as  with  create  DAILY  except  that 
negative  or  positive  values  are  entered  to 
correctly  adjust  the  monthly  and  yearly  totals 
for  a  requested  provider,  treatment  and  month 

B.  Output  Description 

Modified  DAILY  object  in  database 
Modified  MONTHLY  object  in  database 
Updated  YEAR  object  in  database 
Confirmation  message  of  updates  on  screen 
Online  monthly  and  yearly  totals  for  selected 
treatment  and  individual  provider  on  screen 
On  demand  Hardcopy  availability  of  input  data 
for  the  modification  data  entry  session 

C.  Processing  Notes 

The  MONTHLY  object  is  modified  via  the  update 
daily  mechanism  which  updates  the  DAILY  object 
as  well  as  the  MONTHLY 

D.  Volume 

Number  of  treatments  is  dependent  on  the  number 
of  incorrect  daily  entries  made  during  a  given 
month.  Errors  are  generally  corrected  via  the 
validated  daily  provider's  report  which  is 
returned  to  the  DIRS  data  entry  clerk 
Low 
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E.  Frequency 

As  required 

Modification  are  generally  only  needed  due  to 
erroneous  data  entry.  Since  control  mechanism 
are  built  in  the  system  which  prompt  data  entry 
personnel  to  validate  entry  before  entry  is 
accepted  into  the  database,  these  type  of  errors 
are  infrequent 


III.  Delete  MONTHLY  data 

A.  Input  Description 

-  Procedure  same  as  with  update  DAILY  except  that 
negative  values  are  entered  to  correctly 
adjust  the  monthly  and  yearly  totals  for  a 
requested  provider,  treatment  and  month 
The  MONTHLY  object  is  deleted  through  the 
utilities  option  by  selecting  the  start  new  year 
option 

B.  Output  Description 

New  database  structure  created  for  MONTHLY 
object  when  a  new  year  is  started 
Updated  MONTHLY  object  in  database 
Updated  YEAR  object  in  database 
Confirmation  message  of  updates  on  screen 
Online  monthly  and  yearly  totals  for  selected 
treatment  and  individual  provider  on  screen 
On  demand  Hardcopy  availability  of  input  data 
for  the  modification  data  entry  session 

C.  Processing  Notes 

MONTHLY  object  is  automatically  updated  via  the 
update  daily  module 

D.  Volume 

Low 

E.  Frequency 

MONTHLY  object  is  deleted  once  per  year 
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MONTHLY  OBJECT 
Display  Mechanisms 


I .  Monthly  Report 

A.  Output  Description 

Same  as  with  Daily  object  report  except  that 
information  represents  monthly  figures  versus 
daily  totals 

Providers'  statistical  report  used  by  management 
displays  provider  code,  total  number  of 
treatments,  total  CTV,  and  cumulative  command 
totals  for  the  selected  month.  Headquarters  may 
also  produce  similar  report  provided  information 
has  been  imported  from  subordinate  commands 
Major  treatment  report  allowing  user  to  narrow 
its  scope  of  information  by  the  selection  of  up 
to  ten  critical  treatment  codes.  List  providers 
along  with  treatment  codes,  total  number  of 
treatments  and  total  CTV 

B.  Source  data 

Selected  MONTHLY  object 

-  May  be  selected  any  time  during  the  year  for  a 
requested  month 

C.  Processing  Notes 

MONTHLY  object  contains  COMMAND  and  DAILY  object 
data 

Use  at  local  command  and  distributed  to  each 
provider  as  a  feeder  sheet  on  individual 
productivity 

Headquarter  maintains  an  aggregated  MONTHLY 
object  of  all  its  subordinate  command  to  produce 
an  OCR  monthly  report  for  submission  to 
NAVBUMED,  Washington  D.C. 

The  major  treatment  report  is  used  by  management 
for  internal  management  of  provider 
productivity 

A  monthly  report  similar  in  format  to  the 
monthly  OCR  DIRS  report  produced  by  HQ.  Report 
is  not  OCR  font 

A  providers  statistics  report  is  produced 
displaying  information  by  provider  versus  by 
treatment  as  in  the  case  of  monthly  reports 

D.  Volume 

Minimum  three  per  month 

Any  time  during  a  month  for  an  up-to-date  report 
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E.  Frequency 
Monthly 


MONTHLY  OBJECT 
Control  Mechanisms 


I.  Pull-down  menus,  pop-up  windows,  system  validation 
routines,  along  with  user  prompts  provide  suitable 
control  mechanisms 


YEAR  OBJECT 
Update  Mechanisms 


I .  Create  YEAR 

A.  Input  Description 

DAILY  object  automatically  updates  the  YEAR  6 
object 

B.  Output  Description 

Updated  MONTHLY  object  in  database 
Updated  YEARLY  object  in  database 
Online  yearly  totals  for  selected 
treatment  and  individual  provider  on  screen 

C.  Processing  Notes 

The  YEAR  object  in  created  at  the  start  of  a  new 
year.  The  DAILY  object  is  the  feeder  for  the 
YEAR  OBJECT 

D.  Volume 

Average  number  of  different  treatments  per 
provider  is  26  treatments  per  day  times  the 
number  of  work  days  per  year.  Each  clinic 
averages  six  providers  per  work-day  (Monday 
through  Friday) 

E.  Frequency 

As  often  as  the  DAILY  object  is  updated 


II.  Modify  YEAR  data 

A.  Input  Description 

Same  as  with  DAILY  and  MONTHLY  object 
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B.  Output  Description 

Modified  YEAR  object  in  database 
Confirmation  message  of  updates  on  screen 
Online  yearly  totals  for  selected 
treatment  and  individual  provider  on  screen 

C.  Processing  Notes 

The  YEAR  object  is  modified  via  the  update  daily 
mechanism  which  updates  the  DAILY  object  as  well 
as  the  MONTHLY  and  YEARLY  OBJECT  database 
automatically 

D.  Volume 

-  Very  low  since  data  has  generally  been  corrected 
by  the  DAILY  and  MONTHLY  object  update 
mechanisms 

Same  as  per  DAILY  object 

E .  Frequency 

Same  as  per  DAILY  object 


III.  Delete  YEAR  data 

A.  Input  Description 

Procedure  same  as  with  update  DAILY  except  that 
negative  values  are  entered  to  correctly 
adjust  the  yearly  totals  for  a  requested 
provider,  treatment  and  month 

The  YEAR  object  is  deleted  through  the  utilities 
option  by  selecting  the  start  new  year  option 

B.  Output  Description 

New  database  structure  created  for  the  YEAR 
object  when  a  new  year  is  started 
Updated  YEAR  object  in  database 
Conf irmation  message  of  updates  on  screen 
Online  yearly  totals  for  selected 
treatment  and  individual  provider  on  screen 

C.  Processing  Notes 

YEAR  object  is  automatically  updated  via  the 
update  DAILY  object  mechanism 

D.  Volume 

Very  low 

E.  Frequency 

YEAR  object  is  deleted  once  per  year 
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YEAR  OBJECT 
Display  Mechanisms 


I.  Annual  Report 

A.  Output  Description 

Same  as  with  Monthly  report  except  that 
information  represents  the  total  number  of 
treatment  to  date  for  the  given  year 

B.  Source  data 

Selected  YEAR  object 

C.  Processing  Notes 

YEAR  object  contains  COMMAND  and  MONTHLY  object 
data 

Use  at  local  command  and  distributed  to  each 
provider  as  a  feeder  sheet  on  individual 
productivity 

Use  by  management  for  planning  and  budgeting 
function 

Use  by  management  as  a  verification  tools 
against  the  aggregated  monthly  reports 
A  providers  statistics  report  is  produced 
displaying  information  by  provider  versus  by 
treatment  as  in  the  case  of  a  monthly  report 

D.  Volume 

One  per  month 
One  per  year 

Any  time  during  the  year 

E .  Frequency 

Monthly 

Yearly 


YEAR  OBJECT 
Control  Mechanisms 


I.  Pull-down  menus,  pop-up  windows,  system  validation 
routines,  along  with  user  prompts  provide  suitable 
control  mechanisms 
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COMMAND  OBJECT 
Update  Mechanisms 


NOTE:  This  object  is  different  from  typical  objects  as  it 

is  used  solely  as  a  control  mechanism  to  provide  users  a 
more  intuitive,  less  repetitious  system. 

I.  Create  COMMAND  object 

A.  Input  Description 

Unit  Identification  Code  (UIC) 

Command  name 

MEPERS  codes  for  laboratory  and  clinical 
procedures 

B.  Output  Description 

New  COMMAND  object 

Confirmation  message  of  updates  on  screen 

C.  Processing  Notes 

This  information  generally  does  not  change. 
DIRS  is  designed  to  support  one  to  nine  dental 
clinics 

D.  Volume 

One  to  nine  clinics 

E.  Frequency 

Once  at  initial  installation 


II.  Delete  or  Modify  COMMAND  Object 

A.  Input  Description 

Same  as  with  create  COMMAND  object 
At  DOS  prompt  file  "comm. mem"  is  deleted 

B.  Output  Description 

New  COMMAND  object 

C.  Processing  Notes 

This  information  generally  does  not  change 
DIRS  is  designed  to  support  one  to  nine  dental 
clinics 

D.  Volume 

Not  applicable 

E .  Frequency 

Not  applicable 
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COMMAND  OBJECT 
Display  Mechanisms 


I .  Pop-up  windows 

A.  Output  Description 

Help  screens  displaying  and  prompting  user  for 
command  or  MEPERS  selection 

B.  Source  data 

COMMAND  object  (alias  comm. mem) 

C.  Processing  Notes 

Mainly  used  at  headquarter  (HQ)  level  where  user 
must  differentiate  between  commands 

D.  Volume 

Anytime  HQ  wishes  to  print  report  on  a 
particular  clinic 

E .  Frequency 

Varies  from  command  to  command 


COMMAND  OBJECT 
Control  Mechanisms 


I.  Pull-down  menus,  pop-up  windows,  system  validation 
routines,  along  with  user  prompts 


II.  Automatic  UIC  entry 

A.  Output  Description 

Automatically  enters  command  UIC  to  file  that 
will  be  exported  to  HQ 

B.  Source  Data 

COMMAND  object 

C.  Processing  Notes 

User  never  has  to  key-in  command  information  for 
updating  DAILY,  MONTHLY,  or  YEARLY  object  thus 
avoiding  possible  data  validity  and  data  entry 
errors 

D.  Volume 

Same  as  with  DAILY  object  update  mechanisms 
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E.  Frequency 
Daily 


STATS  OBJECT 
Update  Mechanisms 


I.  Create  STATS 

A.  Input  Description 

An  aggregate  of  all  data  segregated  by  month  for 

an  entire  year  on  all  subordinate  commands 

This  object  is  only  maintained  at  HQ 

Created  by  importing  subordinate  command  MONTHLY 

object 

B.  Output  Description 

Updated  STATS  object  at  HQ 

C.  Processing  Notes 

This  object  is  the  major  feeder  for  all  reports 
that  are  generated  by  HQ 

D.  Volume 

MONTHLY  object  for  each  subordinate  clinic 
Approximately  156  records  per  clinic 

E.  Frequency 

Created  once  per  Year 


II.  Modify  STATS  data 

A.  Input  Description 

Monthly  Import  file  from  subordinate  command 

B.  Output  Description 

Updated  STATS  object  at  HQ 

C.  Processing  Notes 

-  Automatically  modified  with  import  of 
subordinate  command 

D.  Volume 

One  to  two  records  per  month  per  clinic 

E.  Frequency 

Once  per  month 
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III.  Delete  STATS  data 


A.  Input  Description 

Monthly  Import  file  from  subordinate  command 

B.  Output  Description 

Updated  STATS  object  at  HQ 

C.  Processing  Notes 

Automatically  modified  with  import  of 
subordinate  command 

The  entire  object  shall  be  delete  once  per  year 
via  menu  selection 

D.  Volume 

Not  applicable  since  extra  treatments  are  not 
added.  Total  number  of  treatments  for  an 
individual  provider  and  treatment  are  sometimes 
modified  but  not  deleted 

E .  Frequency 

Not  applicable 


STATS  OBJECT 
Display  Mechanisms 


I .  Monthly  OCR  Report  and  Providers  Stats  Report 

A.  Output  Description 

An  OCR  form  for  a  selected  clinic  and  month 
which  must  be  printed  on  an  OCR  printer 
A  providers  statistics  report  is  identical  to 
MONTHLY  display  mechanism  except  that  it  shall 
display  all  providers  productivity  within 
chain-of-command  of  HQ 

B.  Source  data 

Selected  STATS  and  COMMAND  objects 

C.  Processing  Notes 

STATS  object  contains  COMMAND  object  data 
Use  by  management  for  planning  and  budgeting 
function 

D.  Volume 

As  many  OCR  reports  as  subordinate  clinics 
Stats  report  is  produced  at  minimum  one  per 
month 
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E .  Frequency 
-  Monthly 
Yearly 


STATS  OBJECT 
Control  Mechanisms 


I.  Pull-down  menus,  pop-up  windows,  system  validation 
routines,  along  with  user  prompts.  A  database 
administrator  will  be  assigned  at  HQ  to  manage  overall 
system  data  integrity 
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APPENDIX  F 


RELATION  DIAGRAM 
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APPENDIX  G 


LOGICAL  MENU  STRUCTURE 


MENU  HIERARCHY 
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APPENDIX  II 


SAMPLE  REPORTS 


NAVAL  DENTAL  CLINIC,  LONG  BEACH,  CA.  12:49:38  01/13/90 

DENTAL  INFORMATION  RETRIEVAL  SYSTEM  SCREEN  #  1.4 


REPORT  MENU 

DAILY  REPORT 
MONTHLY  REPORT 
ANNUAL  REPORT 
PROVIDERS  STATS. 

MAJOR  TREATMENT  REPORT 

RETURN  TO  MAIN  MENU 


USE  UP  AND  DOWN  CURSOR  KEYS  T!  TO  HIGHLIGHT  ITEM  AND 
PRESS<RETURN> 


Branch  Clinic  Report  Menu 


Documents  on  the  following  pages  of  this  appendix  depict 
sample  reports  produced  after  selection  of  menu  options 
presented  from  the  DIRS  Branch  Clinic  Report  Menu  screen 
reproduced  above . 
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02/05/90 
PAGE  1 


DENTAL  INFORMATION  RETRIEVAL  SYSTEM 
DAILY  INPUT  REPORT 


PROVIDER:  117 


BENEFICIARY  CATEGORY  CTV  CTV  CTV 


01  02 

05 

08 

09 

10 

11 

12 

13 

TOTAL 

TOTAL 

NAVY 

RETIRED 

**  TREATMENT 
5.0  0.0 

CODE: 

2.0 

0001 

3.0 

*  * 

22.0 

33.0 

0.0 

0.0 

1.0 

66.0 

132. C 

10.0 

0.0 

*»  TREATMENT 
3.0  0.0 

CODE: 

0.0 

5752 

3.0 

*  * 

34.0 

0.0 

33.0 

0.0 

9.0 

82.0 

344.4 

12.6 

138.6 

PROVIDER  TOTALS 

01  02  05 

BENEFICIARY  CATEGORY 

08  09  10  11 

12 

13 

TOTAL 

CTV 

TOTAL 

CTV 

NAVY 

CTV 

RETIRED 

8.0  0.0 

2.0 

6.0 

56.0 

33.0 

33.0 

0.0 

10.0 

148.0 

476.4 

22.6 

138.6 
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02/05/90 
PAGE  2 


DENTAL  INFORMATION  RETRIEVAL  SYSTEM 
DAILY  INPUT  REPORT 


TOTALS 

01 

FOR  TODAY 

02  05 

BENEFICIARY  CATEGORY 

08  09  10  11 

12 

13 

CTV 

TOTAL  TOTAL 

CTV  CTV 

NAVY  RETIRED 

8.0 

575  2.0 

“ O  sTo  3370  53.0 

0.0 

10.0 

148.0  476.4 

22.6  138.6 
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Page  No. 
02/05/90 


1 


DENTAL  INFORMATION 
RETRIEVAL  SYSTEM 
TREATMENT  REPORT 
FOR  THE  MONTH  OF  JUNE 

CTV  CTV  CTV 

CT01  CT02  CT05  CT08  CT09  CT10  CT11  CT12  CT13  TOTAL  TOTAL  NAVY  RET. 


**  DIRS  0001 
**  Subtotal  ** 

36  00000000  36  02.0  72.0  0.0 

**  DIRS  0002 

**  Subtotal  ** 

700000000  7  28.0  28.0  0.0 

**  DIRS  0003 
**  Subtotal  ** 

500000.  000  5  25.0  25.0  0.0 

**  DIRS  0004 
**  Subtotal  ** 

12  00000000  12  48.0  48.0  0.0 

**  DIRS  0005 
**  Subtotal  ** 

1  0  0  0  0  0  0  0  0  1  5.0  5.0  0.0 

**  DIRS  1006 
**  Subtotal  ** 

26  00000000  26  26.0  26.0  0.0 

**  DIRS  0007 
**  Subtotal  ** 

100000000  1  2.0  2.0  0.0 
*’  DIRS  0010 
**  Subtotal  ** 

18  00000000  18  90.0  90.0  0.0 

**  DIRS  0011 
**  Subtotal  ** 

37  00000000  37  74.0  74.0  0.0 
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Page  No.  11 
02/05/90 


DENTAL  INFORMATION 
RETRIEVAL  SYSTEM 
TREATMENT  REPORT 
FOR  THE  MONTH  OF  JUNE 


CTV  CTV 


CT01  CT02 

CTOS 

CT08 

CTO  9 

CT1 0 

CT11 

CT12 

CT1 3 

TOTAL 

TOTAL 

NAVY 

*  * 

DIRS  9918 

*  * 

Subtotal  ** 
38 

0 

1 

0 

0 

0 

4 

0 

0 

43 

21.5 

19.0 

*  * 

DIRS  9923 

*  * 

Subtotal  ** 
27 

1 

6 

0 

0 

1 

1 

0 

0 

36 

28.8 

21.6 

*  * 

DIRS  9972 

*  * 

Subtotal  ** 
512 

4 

17 

0 

20 

4 

20 

6 

6 

589 

471.2 

409.6 

*  * 

DIRS  9973 

*  * 

Subtotal  ** 
34  6 

0 

17 

0 

8 

8 

23 

3 

0 

405 

445.5 

380.6 

***  Total  *** 
5583 

21 

200 

1 

121 

56 

231 

30 

22 

6265 

5221.8 

4721.3 
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CTV 

RET. 


2.0 

0.8 

16.0 

25.3 

153.6 


Pag*  No.  1 1 

02/24/90 

DENTAL  INFORMATION 
RETRIEVAL  SYSTEM 
YEARLY  TREATMENT  REPORT 


CTV  CTV 


CTO  1  CT02 

CTOS 

CT08 

CT09 

CT10 

CT1 1 

CT 1 2 

CT  1 3 

TOTAL 

TOTAL 

NAVY 

#* 

DIRS  9918 

»# 

Subtotal  ** 
195  1 

7 

0 

2 

0 

25 

1 

2 

233 

116.5 

97.5 

** 

DIRS  9923 

#* 

Subtotal  ** 
255  4 

21 

0 

0 

1 

3 

0 

0 

284 

227.2 

204.0 

DIRS  9972 

#* 

Subtotal  ** 
3769  89 

121 

0 

136 

1  1 

270 

93 

79 

4568 

3654 . 4 

3015. 2 

t* 

DIRS  9973 

«* 

Subtotal  *• 
2222  16 

94 

0 

45 

12 

169 

8 

8 

2574 

2831.4 

2444. 2 

*«•  Total  *** 
40459  532 

1297 

-> 

793 

124 

2329 

432 

357 

46325 

34610.7 

31066.5 

CTV 

RET. 

12.5 

2.4 

216.0 

185.9 

1358.0 
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NAVAL  POSTGRADUATE  SCHOOL,  MONTEREY,  CA. 

Page  No:  1 

PROVIDER  SUMMARY  REPORT 
FOR  THE  MONTH  OF  JUN  1990 


PROVIDER  CODE 

TOTAL  TREATMENT 

TOTAL  VALUE 

112 

45 

25.3 

113 

841 

602.6 

114 

525 

356.0 

117 

1085 

759.2 

119 

756 

436.7 

126 

532 

349.9 

131 

1127 

811.8 

132 

351 

182.8 

133 

210 

1098.0 

425 

793 

599.5 

CUMULATIVE  TOTALS:  6265  5221.8 
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PAGE 


1 


MAJOR  TREATMENT  REPORT 
FOR  THE  MONTH  OF  JUNE 


PROVIDER  TREATMENT  CODES  /  WEIGHTED  VALUES 


0001 

0002 

9918 

9923 

9972 

112 

1/ 

2.0 

0/ 

0.0 

0/ 

0.0 

0/ 

0.0 

7/  5.6 

113 

0/ 

0.0 

0/ 

0.0 

9/ 

4.5 

14/ 

11.2 

114/  91.2 

114 

0/ 

0.0 

0/ 

0.0 

5/ 

2.5 

4/ 

3.2 

60/  48.0 

117 

0/ 

0.0 

0/ 

0.0 

5/ 

2.5 

9/ 

7.2 

87/  69.6 

119 

0/ 

0.0 

0/ 

0.0 

3/ 

1.5 

9/ 

7.2 

31/  24.8 

126 

1/ 

2.0 

0/ 

0.0 

4/ 

2.0 

0/ 

0.0 

29/  23.2 

131 

0/ 

0.0 

0/ 

0.0 

0/ 

0.0 

0/ 

0.0 

113/  90.4 

132 

0/ 

0.0 

0/ 

0.0 

0/ 

0.0 

0/ 

0.0 

148/118.4 

133 

34/ 

68.0 

7/ 

28.0 

0/ 

0.0 

0/ 

0.0 

0/  0.0 

425 

0/ 

0.0 

0/ 

0.0 

17/ 

8.5 

0/ 

0.0 

0/  0.0 

107 


APPENDIX  I 


NAVMED  FORM  6600/11 
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SECTION  I .  INTRODUCTION 


1.  PURPOSE  OF  THE  USER'S  MANUAL 

The  purpose  of  this  User's  Guide  is  to  provide 
guidelines  for  personnel  using  this  Dental  Information 
Retrieval  System  (DIRS)  program.  This  user's  manual  should 
answer  most  questions  concerning  the  operation  of  DIRS. 
Please  take  time  to  read  this  manual  carefully.  Reading  the 
manual  before  installation  may  save  you  a  lot  of  frustration 
and  time  later  on. 

2 .  PROJECT  REFERENCES 

This  guide  is  divided  into  sections,  depending  on  the 
operation  being  performed.  Material  is  presented  in  a  step 
by  step  fashion.  It  is  designed  to  provide  timely  reference 
to  aid  in  resolving  most  problems  that  may  occur  while  using 
DIRS . 

3.  SECURITY  AND  PRIVACY 

The  DIRS  system's  databases  are  unclassified;  therefore 
no  security  clearance  is  required  to  gain  access.  However, 
be  informed  that  each  command  must  have  an  Automatic  Data 
Processing  Security  Plan  (ADPSP) .  It  may  be  advisable  to 
secure  all  spaces  that  contain  Personal  Computers  (PC) . 
Securing  PCs  also  means  protecting  data  from  unauthorized 
personnel  that  could  willingly  or  accidently  destroy  data 
stored  on  PC. 

4.  SYSTEM  OVERVIEW 

The  DIRS  system  is  designed  to  gather  accurate 
information  in  a  relatively  quick  time  frame.  It  will 
replace  the  slow  and  tedious  manual  process  of  producing  the 
monthly  DIRS  report.  The  system  will  also  maintain 
production  data  on  dental  officers  providing  dental 
services,  and  other  support  staff.  The  DIRS  system  is  a 
menu-driven  data  base  system  prepared  as  a  graduate  level 
thesis  project  by  two  students  at  the  Naval  Postgraduate 
School,  Monterey,  Ca.  DIRS  is  designed  so  that  even  non¬ 
computer  personnel  should  be  able  to  operate  the  system 
without  too  much  difficulty  (reading  the  user's  manual  will 
help) . 

5.  SYSTEM  RESPONSIBILITY 

The  Dental  Department  has  custody  of  the  DIRS  system 
and  will  ensure  that  all  files  are  properly  maintained  and 
kept  current.  The  use  of  this  system  is  restricted  to 
personnel  who  are  trained  on  the  IBM  PCs  (or  compatibles)  in 
accordance  with  current  instructions  and  those  specifically 
authorized  in  writing  by  the  Head,  Dental  Department. 
Furthermore,  program  modification  shall  be  the 
responsibility  of  custodial  command. 
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6 .  SYSTEM  CONFIGURATION 

The  DIRS  system  is  simple  to  use  and  does  not  require 
complicated  ADP  equipment.  The  system's  command  files  are 
compiled;  meaning,  dBASE  III  PLUS  does  not  have  to  be 
installed  on  your  PC.  It  is  designed  to  work  on  any  IBM 
compatible  PC.  Reports  are  produced  using  a  near-letter 
quality  printer,  except  for  the  DIRS  reports  that 
headquarters  produce.  An  OCR  scanner  is  used  to  read  the 
DIRS  report  after  it  is  printed;  therefore,  an  OCR  printhead 
must  be  used.  It  is  a  requirement  that  the  printer  will 
accept  this  type  of  printhead.  The  DIRS  system  will  prompt 
the  user  to  switch  to  the  OCR  (auxiliary)  printer  when 
calling  the  monthly  DIRS  Report.  Remember  to  switch  back  to 
your  primary  printer  after  completing  vour  OCR  report. 

7 .  HARDWARE  REQUIREMENTS 

a.  IBM-PC  compatible  computer  W/640K  memory. 

b.  20  megabyte  hard  disk. 

c.  MS-DOS  version  3.0  or  higher. 

d.  An  OCR  10  pitch  daisy  wheel  printer. 


SECTION  II.  SYSTEM  INSTALLATION 

1.  DIRS  INSTALLATION. 

Insert  disk  #1  in  drive  A: .  From  the  root  directory, 
at  the  C:  drive  DOS  prompt,  type  "A: install."  The  install 
program  will  prompt  the  user  for  a  directory  name  where  DIRS 
is  to  be  installed.  Enter  up  to  ten  characters.  The 
install  program  will  create  a  directory  and  copy  the 
necessary  files  to  that  directory.  The  install  program  will 
then  ask  the  user  to  insert  floppy  #2  in  drive  a;,  please  do 
so  at  that  time.  When  installation  is  completed,  a  message 
will  appear  on  screen  indicating  that  installation  is 
complete.  Notice  that  you  are  in  the  newly  created 
directory  where  DIRS  has  been  installed. 

2.  LOADING  COMMAND  INFORMATION  FILE 

To  run  DIRS,  type  "DIRS"  in  the  directory  where  DIRS 
has  been  installed.  Several  screens  will  appear  prompting 
the  user  for  vital  system  and  command  information.  The 
screens  presented  below  are  similar  to  those  that  the  user 
will  see. 

As  you  are  operating  the  program,  you  will  be  directed 
by  the  'COMMAND  NAME'  and  'SYSTEM  NAME'  prompts  to  enter  the 
name  of  your  command  and  title  your  DIRS.  We  recommend  that 
you  title  the  system  'DENTAL  INFORMATION  RETRIEVAL  SYSTEM' 
since  that  is  the  function  of  the  system.  Keep  in  mind  that 
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fields  A  and  B  are  used  to  title  the  upper  left  corner  of 
all  the  menus  presented  in  DIRS.  See  Figure  (1)  for  an 
example  of  screen  heading  (upper  left  corner) .  In  a  sense, 
you,  the  user  are  actually  customizing  the  system  to  fit 
your  personal  taste  and  requirements.  Field  C  is  simply  a 
prompt  requesting  the  number  of  clinics  that  will  be 
supported  by  your  command.  For  example,  if  you  are  a  branch 
clinic,  ship,  or  a  stand-alone  independent  clinic,  enter 
one.  On  the  other  hand,  a  headquarters  command  which  will 
be  requesting  information  from  its  subordinate  clinics 
should  enter  the  number  of  subordinate  clinics  and  itself  as 
the  correct  number  to  be  supported. 

If  an  error  as  been  made  in  the  data  entered,  field  D 
will  allow  the  user  to  reenter  the  data  by  entering  an  'N' 
(No),  in  that  field.  Answering  'Y'  (Yes),  will  generate 
another  screen  prompting  you  with  fields  (E-G) .  Enter  your 
command  Unit  Identification  Code  (UIC)  in  Fields  E.  Note 
that  field  E  will  only  tolerate  numeric  values  to  be 
entered.  Leave  a  space  then  insert  a  dash  (-)  followed  by 
another  space  before  entering  the  official  command  name.  It 
is  important  that  the  official  command  be  entered  correctly 
since  what  you  input  in  this  field  is  the  exact  data  to  be 
output  on  several  reports  generated  by  DIRS.  Fields  F&G  are 
the  UCA  codes  presently  associated  with  your  DIRS  reporting 
procedure.  Again  the  system  will  prompt  to  see  if  data  is 
correct.  Answering  'N'  (No)  to  this  prompt  will  allow 
correction  to  be  made.  Note  that  it  does  not  matter  whether 
your  data  is  entered  in  upper  or  lower  case,  DIRS  will 
default  to  upper  case. 


(Initial  setup  screen  #1) 

"The  following  information  should  only  be  entered  once. 
DIRS  will  remember  the  information  that  you  are  about 
to  enter.  If  unsure  of  what  you  must  enter,  see  the 
user's  manual.  PLEASE  ANSWER  THE  FOLLOWING:" 

COMMAND  NAME:  (Field  A) 

SYSTEM  NAME:  (Field  B) 


"HOW  MANY  CLINICS  WILL  DIRS  BE  SUPPORTING  (1-9):"  (Field  C) 

"DATA  CORRECT  (Y/N) ?"  (Field  D) 
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(Initial  setup  screen  #2) 


UCA  CODES 
LAB  -  CLINICAL 

UIC  -  CLINIC  NAME  DIRS  CODE  <0097  -  0096> 

Example:  55555  -  PORT  NEVERSAIL  CCYA  CAYA 

ENTER  UIC:  (Field  E)  UCA  CODE:  (Fields  F  &  G) 


"DATA  CORRECT  (Y/N)?»  (Field  D) 


3.  COMMAND  INFORMATION  FILE  CORRECTION 

Ok,  so  you  followed  all  the  instructions  and  still 
managed  to  enter  incorrect  information.  The  main  menu  is 
displayed  and  you  don't  like  the  system  title  block.  To 
change  the  information  specified  in  section  II,  paragraph  2, 
exit  DIRS  by  selecting  "QUIT"  from  the  main  menu.  You 
should  now  be  at  the  C:  prompt  in  the  directory  where  dirs 
has  been  installed.  Type  "DEL  COMM. MEM"  then  type  "DIRS." 
The  RAM  (Random  Access  Memory  file)  will  be  deleted  allowing 
you  to  recreate  this  RAM  resident  file  as  per  directions 
stated  in  section  II,  paragraph  2. 


4.  LOADING  ESSENTIAL  FILES 

Before  any  daily  input  can  be  entered,  provider 
information  must  be  entered.  After  all,  how  can  one  record 
treatment  procedures  on  a  provider  without  a  provider?  The 
provider  file  must  be  completed  before  any  data  can  be 
entered.  It  is  recommended  that  a  range  of  valid  provider 
codes  be  assigned  to  each  department  or  clinic.  It  is  also 
suggested  that  ranges  have  some  type  of  meaningful 
relationship  to  a  particular  clinic  or  UIC,  i.e.:  100-200 
would  be  providers  from  clinic  A,  201-300  would  be  providers 
from  clinic  B,  and  so  on.  Another  suggestion  is  to  end  the 
provider  code  with  an  odd  or  even  configuration.  For 
example,  105  would  represent  a  two-week  active  duty 
reservist.  100  would  represent  a  full-time  provider. 

Section  III  provides  instructions  on  how  to  add,  edit,  or 
delete  a  provider. 

The  Dirs  treatment  database  has  already  been  completed 
with  the  most  common  codes  used.  This  database  may  be 
updated  if  need  be,  by  following  the  instructions  in  section 
III . 
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SECTION  III.  OPERATION  PROCEDURES 


1 .  START-UP  PROCEDURES 

The  start-up  procedure  is  designed  for  those  with 
absolutely  no  computer  background.  Those  of  you  with  basic 
''DOS'1  and  PC  knowledge  may  choose  to  overlook  this  brief 
paragraph. 

Turn  on  your  computer.  Now  that  your  computer  is  on, 
check  to  see  if  your  peripheral  devices  are  on  (printers, 
power  director,  display  terminal,  etc.).  When  everything  is 
turned  on,  change  directories  to  the  directory  that  contains 
DIRS.  This  can  be  achieved  by  typing  "CD\di rectory  name" 
where  "directory  name"  is  the  name  that  you  ha^^e  selected  to 
label  your  directory.  Now  type  "DIRS,"  this  command  will 
bring  up  the  main  menu  or  the  memory  screen  discussed  in 
Section  II,  if  it  has  not  already  been  loaded. 

2 .  OPERATION  PROCEDURES 

Using  this  system  is  simply  a  matter  of  doing  what  the 
computer  tells  you  to  do.  Your  DIRS  system  is  fully  menu 
driven.  Menu  driven  means  that  you  can  select  any  option 
from  the  menu  by  simply  moving  the  arrows  (ti)  until  you 
have  highlighted  your  desired  selection.  You  can  also 
select  an  option  by  pressing  the  first  letter  of  the  desired 
option,  but  in  the  event  that  two  menu  items  start  with  the 
same  letter,  the  system  will  default  to  the  first  selection. 
The  most  complicated  thing  about  this  system  is  getting  over 
the  phobia  generally  associated  with  computers.  Remember  to 
relax  and  read  what  the  computer  is  prompting  you  to  do. 
Reading  prompts  (the  messages  that  the  system  displays  when 
it  wants  you  to  do  something)  is  generally  the  key  to 
success  when  using  any  menu  driven  system. 


SECTION  IV.  MAIN  MENU  AND  SUB  MENU. 

The  diagram  provided  on  the  next  page  titled;  "Menu 
Hierarchy,"  should  provide  a  helpful  overview  of  the  various 
menu  screens  available  in  DIRS  should  you  get  lost  in  a 
particular  level  or  just  want  a  ready  reference  to  a 
destination  or  operation  of  choice.  You  may  find  it  helpful 
to  enlarge  the  diagram  and  post  it  in  a  convenient  location 
until  you  gain  familiarity  with  the  system. 


US 


MENU  HIERARCHY 


1. 


THE  MAIN  MENU 
Heading 


A 


B 


NAVAL  DENTAL  CLINIC,  USN  13:17:17  01/13/90 

DENTAL  INFORMATION  RETRIEVAL  SYSTEM  SCREEN  #  1.0 


MAIN  MENU 

INPUT  DIRS  DATA 

CHANGE  DIRS  CODES 

UPDATE  PROVIDER  CODES 

QUERIES 

FILE  UTILITIES 

HEADQUARTERS  ONLY 

QUIT 


USE  UP  AND  DOWN  CURSOR  KEYS  ti  TO  HIGHLIGHT  ITEM  AND 
PRESS<RETURN> 


Prompt  &  Status  Box 

Figure  1.  Main  Menu  Screen 


To  operate  the  DIRS  system,  enter  the  first  letter 
which  corresponds  to  the  item  in  the  menu  body  that  you  want 
to  select,  or  move  the  arrow  keys  (ti)  to  highlight  your 
choice.  All  menus  have  a  RETURN  option  to  return  to  the 
calling  Menu.  Note  that  the  heading  section  of  the  menu 
above,  displays  the  command  name  and  system  title  that  you 
have  selected  and  entered  at  initial  installation.  The 
upper  right  corner  of  the  menu  displays  such  information  as 
current  date,  time,  and  screen  number.  All  menus  within 
DIRS  support  this  type  of  display.  The  body  or  middle  of 
the  screen  displays  options  available.  The  option  may  be 
selected  as  per  stated  in  the  bottom  section  of  the  screen. 
This  bottom  section  is  the  area  that  the  user  should  pay 
particular  attention  to,  since  error  messages  and/or  user 
prompts  will  be  displayed  there.  The  system  will  also  beep 
when  invalid  or  incorrect  data  has  been  input. 

2.  INPUT  DIRS  DATA 

The  first  screen  that  will  appear  when  selecting  option 
one  (INPUT  DIRS  DATA)  is  displayed  below  (Figure  2) .  Enter 
"Y"  (yes) ,  if  the  displayed  month  is  the  desired  month  for 
data  entry.  Enter  "N"  (no)  to  select  another  month.  When 
"N"  is  selected  a  window  will  appear  displaying  options  that 
may  be  keyed  in  at  the  prompt  (see  Figure  3) .  The  default 

month  (open  month  on  screen)  is  the  current  calendar  month 
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month  (open  month  on  screen)  is  the  current  calendar  month 
based  on  the  computers  system  clock. 


NAVAL  DENTAL  CLINIC,  USN  08:05:14  01/13/90 

DENTAL  INFORMATION  RETRIEVAL  SYSTEM  SCREEN  #  1.1.1 


OPEN  MONTH  IS  JANUARY 


IS  THIS  CORRECT?  Y/N 

Figure  2.  Input  DIRS  Data  (Open  Month  Confirmation) 


NAVAL  DENTAL  CLINIC,  USN  09:02:20  01/13/90 

DENTAL  INFORMATION  RETRIEVAL  SYSTEM  SCREEN  #  1.1.1 


JAN 

JUL 

FEB 

AUG 

MAR 

SEP 

APR 

OCT 

MAY 

NOV 

JUN 

DEC 

ENTER  THREE  LETTERS  OF  NEW  MONTH: 


Figure  3 .  Month  Input  Screen 


To  select  the  correct  month,  the  three  letter 
abbreviation  is  entered  at  the  prompt.  For  example,  typing 
JUN  in  the  month  selection  screen  will  the  month  of  June  for 
data  entry.  Once  the  desired  month  has  been  opened,  the 
provider  prompt  screen  will  follow. 

To  select  a  provider,  the  provider  code  may  be  entered 
directly  if  the  code  is  known,  or  by  pressing  the  <HOME> 
key,  an  additional  window  with  the  valid  provider  codes 
assigned  to  the  reporting  command  will  pop  up.  From  the 
available  valid  provider  codes  on  screen,  the  corresponding 
number  that  matches  the  desired  provider  code  may  be 
entered.  (See  Figures  (4)  &  (5)). 
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NAVAL  DENTAL  CLINIC,  USN  08:18:58  01/13/90 

DENTAL  INFORMATION  RETRIEVAL  SYSTEM  SCREEN  #  1.1.1 


PROVIDER  CODE: 


ENTER  PROVIDER  CODE  OR  PRESS  <HOME>  FOR  HELP 


Figure  4.  Provider  Code  Entry  Screen 


NAVAL  DENTAL  CLINIC,  USN 
DENTAL  INFORMATION  RETRIEVAL 

08:18:58  01/13/90 

SYSTEM  SCREEN  #1.1.1 

PROVIDER  CODE 

RANK 

NAME 

1. 

100 

CDR 

NAVY,  JOSEPH 

2  . 

200 

LT 

NAVY,  SON 

3. 

300 

LT 

MESIAL,  DECAY 

4. 

400 

CAPT 

TOOTH,  DECAY 

5. 

455 

LT 

RESERVE,  DENTIST 

6. 

500 

CDR 

BUCKLE,  PIT 

7. 

600 

LT 

LINGUAL,  DISTAL 

8. 

700 

ADM 

DENTAL,  SERVICE 

PRESS 

NUMBER  OF  ITEM 

,  RETURN 

TO  CONTINUE,  OR  "Q"  TO  QUIT 

Figure  5.  Provider  Codes  Screen 


To  select  a  valid  provider,  enter  the  matching  number 
in  the  leftmost  column,  i.e.:  entering  number  "l”  would 
select  provider  100;  CDR  Navy.  The  provider  code  may  also 
be  entered  directly  on  the  provider  input  screen.  This 
method  of  provider  data  entry  provides  a  method  to  check  the 
provider  code  file  to  validate  a  correct  provider  code  for 
the  reporting  unit.  Entering  an  erroneous  code  (a  code  not 
currently  in  the  provider  code  file)  results  in  an  error 
message  indicating  that  fact,  and  further  prompts  the  user 
to  enter  another  code.  When  the  provider  field  is  correctly 
entered,  the  screen  displayed  in  Figure  6  will  follow, 
prompting  the  user  to  enter  a  valid  treatment  code.  As 
previously  discussed,  to  escape  the  DIRS  entry  routine, 
press  <RETURN>  at  a  blank  DIRS  field.  The  "ESC"  key  provides 
another  escape  route  by  allowing  the  user  to  select  the 
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another  escape  route  by  allowing  the  user  to  select  the 
cancel  option  that  will  pop-up  in  the  upper  left  corner  of 
the  screen.  This  escape  feature  will  return  the  user 
completely  back  to  the  DOS  C:  prompt. 


NAVAL  DENTAL  CLINIC,  USN  08:05:14  01/13/90 

DENTAL  INFORMATION  RETRIEVAL  SYSTEM  SCREEN  #  1.1.2 


Entering  Data  for  Provider:  CDR  JOSEPH  NAVY  CODE:  100 


PRESS  THE  <H0ME>  KEY  FOR  A  LIST  OF  DIRS  CODES  TO 
SELECT  FROM. 

PRESS  <RETURN>  ON  AN  EMPTY  FIELD  TO  RETURN  TO  THE 
MAIN  MENU. 


ENTER  DIRS  CODE: 


Figure  6.  DIRS  Treatment  Code  Entry  Screen 

Pressing  the  <HOME>  key  will  display  all  valid  DIRS  codes 
such  as  presented  in  Figure  7 . 


NAVAL  DENTAL  CLINIC,  USN  08:05:14  01/13/90 

DENTAL  INFORMATION  RETRIEVAL  SYSTEM  SCREEN  #  1.1.2 


DIRS 

CODE 

DESCRIPTION 

WEIGHT 

1. 

0001 

POUR  CAST 

2.0 

2. 

0002 

POUR  CAST,  FX 

4.0 

3  . 

0003 

BOX  AND  POUR 

5.0 

4  . 

0004 

IMP  TRAY  CUS 

4.0 

5. 

0005 

POUR  ALT  CAS 

5.0 

6. 

0006 

ARTIC.  SIMPL 

1.0 

7. 

0007 

ARTIC.  SEMI 

1.5 

8. 

0008 

ARTIC.  FULL 

2.0 

9. 

0009 

SOLDER/PER  AREA 

4.0 

PRESS  NUMBER  OF  ITEM,  RETURN  TO  CONTINUE,  OR  "Q"  TO  QUIT 
Figure  7.  DIRS  Treatment  Codes 
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The  DIRS  treatment  code  may  also  be  entered  directly  on 
the  DIRS  prompt  screen  or  the  <HOME>  key  may  be  used  to 
assist  the  user  in  the  event  that  the  correct  DIRS  code  is 
unknown.  This  help  function  is  not  a  mandatory  input 
procedure,  if  you  know  the  correct  code,  entering  it 
directly  will  save  time. 

To  select  a  DIRS  treatment  code,  the  corresponding 
number  displayed  in  the  leftmost  column  is  selected  by 
typing  the  appropriate  number  ("l,,-"9")  .  Pressing  the  <Page 
Down>  or  <Page  Up>  keys  will  scroll  through  the  list  to 
display  other  treatment  codes. 

After  a  valid  provider  and  treatment  code  have  been 
selected  the  following  screen  (Figure  8)  will  appear: 


NAVAL  DENTAL  CLINIC 

,  USN 

12:04:39 

01/13/90 

DENTAL  INFORMATION 

RETRIEVAL  SYSTEM 

SCREEN  # 

1.1.3 

Entering  Data  for 

Provider:  TEST 

TEST  TEST 

CODE:  100 

DIRS  Code:  0120 

Additions 

Totals 

Year 

Beneficiaries 

to  File 

in  File 

to  Date 

Category  1 

0 

0 

0 

Category  2 

0 

0 

0 

Category  5 

0 

0 

0 

Category  8 

0 

0 

0 

Category  9 

0 

0 

0 

Category  10 

0 

0 

0 

Category  11 

0 

0 

0 

Category  12 

0 

0 

0 

Category  13 

0 

0 

0 

ENTER  NEW  VALUES 

AND  PRESS  RETURN 

Figure  8.  DIRS  Data  Entry  Screen 


Data  entry  for  an  individual  provider  is  accomplished 
using  screen  1.1.3,  (depicted  in  Figure  8)  by  entering  the 
correct  quantity  of  procedures  completed  in  each  dental 
beneficiary  category.  A  listing  with  a  brief  definition  of 
each  beneficiary  category  code  is  provided  in  the  diagram  on 
the  next  page. 

The  < RETURN >  key  is  used  to  move  the  cursor  to  the  next 
field  for  data  entry.  The  steps  listed  above  are  repeated 
until  the  user  has  completed  data  entry  for  a  particular 
provider.  Data  entry  error  corrections  are  accomplished  in 
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BENEFICIARY  CODES: 

01  -  Active  Duty,  U.S.  Navy 

02  -  Active  Duty,  U.S.  Marine  Corps 

05  -  Active  Duty,  Other  Services 

08  -  Recruit,  U.S.  Navy  or  Marine  Corps 

09  -  Dependents  of  Active  Duty 

U.S.  Uniformed  Services  Personnel 

10  -  Dependents  of  Retired  or  Deceased 

U.S.  Uniformed  Services  Personnel 

11  -  Retired  Uniformed  Services  Personnel 

12  -  Other  Personnel  not  listed  in  Codes 

01  through  11  and  13 

13  -  Dependent  Children, 

(17  &  under  and  unmarried) 


a  number  of  ways.  The  user  is  prompted  with  the  folowing 
query  at  the  bottom  of  screen  1.1.3?  "Is  this  data  correct? 
Y/N".  A  negative  response  indicated  by  typing  the  "N"  key, 
will  allow  the  user  to  reenter  the  correct  data.  The  user 
may  overwrite  the  data  displayed  on  screen  by  moving  the 
cursor  using  the  arrow  keys  to  the  correct  field  and 
reentering  the  correct  quantity.  Deletion  and  editing  of 
values  previously  entered  for  a  particular  month  is 
accomplished  by  selecting  the  desired  month,  provider,  and 
treatment,  and  entering  an  appropriate  negative  value  to 
either  cancel  or  modify  the  monthly  total  for  the  selected 
record. 

To  return  to  the  main  menu,  the  <RETURN>  key  is  pressed  with 
the  cursor  on  a  blank  DIRS  input  field  or  typing  "Q"  when 
prompted  from  the  help  screen. 

When  a  month  and  provider  have  been  selected,  the  user 
may  continue  adding  new  treatment  data  without  returning  to 
the  main  menu  for  each  instance.  To  enter  data  for  another 
provider,  the  user  must  return  to  the  main  menu  and  select 
the  desired  month  and  treatments.  The  system  will  default 
to  the  month  of  last  data  entry.  Upon  termination  of  a  data 
entry  session,  a  final  query  will  prompt  the  user  with  the 
following  message;  "Do  you  wish  to  save  this  data?  Y/N." 
Selecting  "N"  will  not  save  the  data  entered  during  the 
session.  This  particular  feature  provides  a  control 
mechanism,  allowing  the  user  to  correct  or  terminate  a  data 
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entry  session  without  arbitrary  input  of  inadequately 
screened  or  inaccurate  data  to  the  database.  Selecting  "Y" 
will  automatically  result  in  appropriate  updates  to  the 
Daily,  Monthly,  and  Yearly  files.  Selection  of  "Y"  will 
also  result  in  the  display  of  the  following  messages  in  the 
status  box  located  at  the  bottom  of  the  screen;  "Adding  to 
Monthly  Total"  and  "Adding  to  Yearly  Total,"  informing  the 
system  user  of  action  in  progress. 

3.  Change  DIRS  Codes 

Selection  2  from  the  main  menu  should  be  selected  when 
you  wish  to  add,  delete,  edit,  or  list  your  DIRS  (treatment) 
codes  (Figure  9) .  Deleting  means  erasing  of  an  existing 
code.  Editing  means  changing  an  existing  code.  Please  note 
that  though  some  of  the  most  common  DIRS  treatment  codes 
have  already  been  entered,  this  does  not  mean  that  all  the 
codes  that  your  clinic  uses  have  been  entered.  When  calling 
these  functions,  the  system  works  in  the  same  manner  as  the 
DIRS  entry  section  except  that  a  month  does  not  have  to  be 
opened. 


NAVAL  DENTAL  CLINIC,  USN  12:47:51  01/13/90 

DENTAL  INFORMATION  RETRIEVAL  SYSTEM  SCREEN  #  1.2 


DIRS  CODES  MENU 

ADD  CODE 
EDIT  CODE 
DELETE  CODE 
LIST  CODES 
RETURN  TO  MAIN  MENU 


USE  UP  AND  DOWN  CURSOR  KEYS  t  i  TO  HIGHLIGHT  ITEM  AND 
PRESS<RETURN> 


Figure  9 .  Change  DIRS  Codes  Menu 


4 .  Update  Provider  Codes 

The  function  of  the  Update  Provider  Codes  menu  (Figure 
10)  is  similar  to  that  described  above  for  Change  DIRS 
Codes.  In  this  instance,  rather  than  the  treatment  codes, 
the  update  function  and  display  function  pertains  to  the 
provider  at  a  given  command.  Again,  the  command  listing  of 
providers  is  provided  as  a  convenience  to  the  system  user. 
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NAVAL  DENTAL  CLINIC,  LONG  BEACH,  CA.  12:47:51  01/13/90 

DENTAL  INFORMATION  RETRIEVAL  SYSTEM  SCREEN  #  1.3 


PROVIDERS  CODE  MENU 
ADD  CODE 
EDIT  CODE 
DELETE  CODE 
LIST  CODES 
RETURN  TO  MAIN  MENU 


USE  UP  AND  DOWN  CURSOR  KEYS  ti  TO  HIGHLIGHT  ITEM  AND 
PRESS<RETURN> 


Figure  10.  Update  Provider  Codes  Menu 


NAVAL  DENTAL  CLINIC,  USN 
DENTAL  INFORMATION  RETRIEVAL 

SYSTEM 

3:18:52  11/10/89 

SCREEN  #  1.3.2 

PROVIDER  CODE: 

100 

LAST  NAME: 

NAVY 

FIRST  NAME: 

NAVY 

RANK: 

CDR 

STATUS : 

0 

ENTER 

(R)  =  Reserve 

(C)  =  Contract 

(O)  =  Other  <Return> 

ENTER  CORRECT  PROVIDER 

INFORMATION 

Figure  11.  Provider  Code  Data  Entry  Screen 


Note  the  upper  left  corner  of  Figure  11.  The  screen 
number  is  now  SCREEN  #1.3.2.  The  two  means  that  you  are  now 
in  the  edit  module  under  option  three  (UPDATE  PROVIDER 
CODES) .  All  screen  within  this  system  provide  such 
information.  Figure  11  shows  a  prompt  labelled  "status." 

You  can  enter  one  of  three  things  here  as  stated  on  the 
screen.  When  entering  "R"  you  are  telling  the  system  that 
the  provider  is  a  reservist.  "C"  implies  that  the  provider 
is  contracted  personnel  and  "O"  is  all  other  personnel. 
Whether  selecting  add,  edit,  or  delete,  the  screen  depicted 
in  Figure  12  will  be  used. 


127 


5. 


Report  Menu 

The  Report  menu  (Figure  12)  presents  the  user  with  a 
number  of  options  related  to  reporting  of  DIRS  data  by 
various  chronological  periods.  Using  the  options  available 
in  this  menu,  the  current  total  of  treatments,  treatments  by 
provider,  by  command,  etc.  may  be  obtained.  For  example, 
the  DAILY  REPORT  will  repeat  all  information  keyed-in  via 
the  "INPUT  DIRS  DATA"  selection.  Also  note  that  you  will  be 
asked  whether  or  not  you  would  like  a  daily  report  every 
time  you  exit  the  system.  Naturally,  if  no  data  has  been 
entered  for  that  day  no  report  will  be  generated. 

Additionally,  a  Major  Treatment  Report  option  is 
available  as  a  menu  selection  for  internal  reporting 
purposes.  Please  note  that  the  major  report  will  query  on 
up  to  ten  user  defined  treatment  code.  Please  note:  you 
must  either  change  the  printer  font  size  (pitch)  to  17 
pitch,  or  use  wide  printer  paper  for  the  report  to  fit  with 
seven  or  more  treatments.  The  system  will  forewarn  you  in 
the  event  that  wider  paper  is  required. 


NAVAL  DENTAL  CLINIC,  LONG  BEACH,  CA.  12:49:38  01/13/90 

DENTAL  INFORMATION  RETRIEVAL  SYSTEM  SCREEN  #  1.4 


REPORT  MENU 

DAILY  REPORT 
MONTHLY  REPORT 
ANNUAL  REPORT 
PROVIDERS  STATS. 

MAJOR  TREATMENT  REPORT 

RETURN  TO  MAIN  MENU 


USE  UP  AND  DOWN  CURSOR  KEYS  Tl  TO  HIGHLIGHT  ITEM  AND 
PRESS<RETURN> 


Figure  12.  Branch  Clinic  Report  Menu 


6.  File  Utilities  Menu 

The  menu  screen  presented  in  Figure  13  offers  the 
system  user  the  ability  to  reindex,  backup,  transfer,  and 
start  a  new  recording  year  all  from  within  the  DIRS 
application.  Providing  these  necessary  functions  from 
within  the  system  as  menu-driven  options  helps  simplify  the 
normally  onerous  and  often  neglected  tasks  such  as  backing 
up  the  system  data. 
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NAVAL  DENTAL  CLINIC,  LONG  BEACH,  CA.  13:50:16  01/13/90 

DENTAL  INFORMATION  RETRIEVAL  SYSTEM  SCREEN  #  1.5 


FILE  UTILITIES 

REINDEX  DATA  FILES 
BACKUP  DATA  FILES 
START  NEW  YEAR 
TRANSFER  DATA  TO  DISK 
RETURN  TO  MAIN  MENU 


USE  UP  AND  DOWN  CURSOR  KEYS  1 4.  TO  HIGHLIGHT  ITEM  AND 
PRESS<RETURN> 


Figure  13.  File  Utilities  Menu 


The  reindex  data  files  option  should  be  selected  when 
the  system  shows  signs  of  incorrect  operation  such  as 
incorrectly  assigned  totals  or  data.  As  an  example,  reports 
may  display  zero  work  for  all  providers  at  a  specified 
command  for  a  given  month.  If  this  information  is 
incorrect,  using  the  reindex  option  will  reassign  the 
appropriate  key  field  to  their  respective  records.  The 
reindex  feature  is  often  required  in  any  database  system. 
Power  surges,  improper  file  closing  and  hardware 
malfunctions  are  examples  of  possible  causal  factors  for 
’ndex  distortion.  The  reindex  option  is  provided  to 
reestablish  the  proper  links  and  pointers  to  correct  the 
potential  damage  caused  by  these  malfunctions. 

Selecting  the  backup  data  files  option  will  store  all 
data  on  floppy  disks.  Be  aware  that  your  diskette  must  be 
formatted  before  any  data  can  be  captured  on  disk.  See  your 
DOS  manual  on  formatting  floppies.  It  is  strongly 
recommended  that  backups  be  made  at  least  once  per  week. 
Remember  PCs  are  mechanical  in  nature.  Should  your  PC 
breakdown,  having  a  current  backup  will  save  you  many  hours, 
if  not  days,  of  data  reentry. 

The  "Start  New  Year”  option  is  provided  when  the  users 
wish  to  begin  recordkeeping  functions  for  a  new  reporting 
year;  either  calendar,  fiscal  or  other  arbitrary  selection. 
Failure  to  select  this  option  when  starting  a  new  reporting 
period  will  result  in  overwritten  data  values  and  incorrect 
totals  for  the  selected  period. 

The  "Transfer  Data  to  Disk"  optior  is  selected  to 
transfer  data  for  a  monthly  reporting  period  to  a  "floppy 
disk"  for  subsequent  export  to  the  appropriate  Headquarters 
command.  Production  of  the  OCR  report  form  may  only  be 
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accomplished  at  the  Headquarters  level  after  import  of  the 
transfer  files. 

The  transfer  routine  will  transfer  the  working  file  to 
a  floppy  disk.  The  UIC  window  located  in  the  lower  right 
corner  depicted  in  Figure  14,  prompts  the  user  to  select  a 
number;  1  through  5.  The  number  "5"  is  representative  of  a 
Headquarters  command  with  five  subordinate  DTFs .  This 
number  will  reflect  the  actual  number  of  DTFs  supporting  as 
few  as  one  or  as  many  as  nine.  If  the  system  is  being  used 
at  a  branch  clinic,  only  one  UIC  is  displayed  and  selected. 
User  input  of  the  correct  UIC  is  critical,  because  a  UIC 
FIELD  will  be  appended  on  the  TRANS.  FILE  based  on  the  UIC 
input.  The  TRANS.  FILE  is  the  database  export  file  to  be 
received  by  the  corresponding  Headquarters  command.  This 
routine  will  be  selected  when  a  subordinate  DTF  is  required 
to  submit  data  to  headquarters.  Regardless  of  transmission 
medium,  the  export  routine  must  be  selected  to  transfer  all 
data  to  floppy  disk,  prior  to  submission  of  the  updated 
monthly  data  requirements.  The  export  procedure  described 
above  provides  a  necessary  if  subtle  control  mechanism 
ensuring  that  data  back-ups  are  performed  at  least  once  a 
month.  When  properly  labeled  with  the  appropriate  UIC,  and 
month  of  transfer,  the  floppy  disks  containing  the  TRANS 
database  file  (dbf)  provide  a  convenient  source  of  back-up 
data.  The  menu  status  box  (part  C)  will  provide  a  prompt  to 
insert  a  floppy  disk  into  the  appropriate  drive,  and  a 
message  indicating  the  number  of  records  transferred. 


NAVAL  DENTAL  CLINIC,  USN  13:51:59  11/10/89 

DENTAL  INFORMATION  RETRIEVAL  SYSTEM  SCREEN  #  1.5.4 


ENTER  UIC: 

ENTER  MONTH  OF  REPORT: 

i .  e.  : 


1) 

***  VALID  UIC  *** 

00000  -  HQ  &  NOWHERE 

2) 

55555 

-  PORT  NEVERSAIL 

3) 

55511 

-  POINT  HERE 

4) 

51515 

-  CHINA 

5) 

99999 

-CO  BEACH 

0) 

RETURN 

TO  MAIN  MENU 

SELECT  (0 

-  5)  ?  0 

Figure  14.  File  Transfer  Screen 
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7. 


Headquarters  Menu 

The  Headquarters  menu  (Figure  15)  is  intended  for  the 
Headquarters  command  to  facilitate  the  transfer  of  DIRS  data 
from  subordinate  dental  commands,  and  the  obligatory 
submission  of  DIRS  reports.  To  that  end,  file  import/ export 
facilities  are  provided  as  menu  options  tor  operation  from 
within  the  DIRS  application. 


NAVAL  DENTAL  CLINIC,  LONG  BEACH,  CA.  13:53:44  01/13/90 

DENTAL  INFORMATION  RETRIEVAL  SYSTEM  SCREEN  #  1.6 


HEADQUARTER'S  MENU 

IMPORT  FILES 
EXPORT  FILES 
DO  REPORTS 

START  NEW  YEAR  (HQ  ONLY) 
RETURN  TO  MAIN  MENU 


USE  UP  AND  DOWN  CURSOR  KEYS  ti  TO  HIGHLIGHT  ITEM  AND 
PRESS<RETURN> 


Figure  15.  Headquarter's  Menu 


7.1.  IMPORT  FILES . 

The  "IMPORT  FILES"  option  is  provided  to  receive  files 
transmitted  from  subordinate  commands. 

7.2.  EXPORT  FILES . 

Similarly,  the  "EXPORT  FILES"  option  is  provided  to 
allow  a  Headquarters  command  to  send  a  pre-selected  month  of 
data  for  all  of  its  subordinate  commands. 

7.3.  DO  REPORTS . 

Selection  of  the  "DO  REPORTS"  option  will  result  in 
the  display  of  the  screen  presented  in  Figure  16  with 
provisions  for  selection  of  either  the  DIRS  OCR  format 
monthly  report  or  a  "PROVIDERS  STATS."  internal  report 
option. 
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NAVAL  DENTAL  CLINIC,  LONG  BEACH,  CA.  13:53:44  01/13/90 

DENTAL  INFORMATION  RETRIEVAL  SYSTEM  SCREEN  #  1.6.2 


HEADQUARTER'S  REPORTS 

MONTHLY  DIRS  REPORT 
PROVIDER  STATS. 

RETURN  TO  MAIN  MENU 


USE  UP  AND  DOWN  CURSOR  KEYS  ti  TO  HIGHLIGHT  ITEM  AND 
PRESS<RETURN> 


Figure  16.  Headquarters  Reports 


A.  MONTHLY  DIRS  REPORT 

The  "MONTHLY  DIRS  REPORT"  selection  option  is  supported 
by  the  menu  screen  presented  in  Figure  17.  This  selection 
will  enable  the  Headquarters  to  print  the  standard  monthly 
NAVMED  6600/8  OCR  form  required  for  submission  of  DIRS  data 
to  COMNAVMEDCOM  using  an  OCR  font  capable  printer. 


NAVAL  DENTAL  CLINIC,  LONG  BEACH,  CA.  11:50:26  11/10/89 

DENTAL  INFORMATION  RETRIEVAL  SYSTEM  SCREEN  #  1.5.1 


SELECT  UIC :  00000 


Name  of  Facility:  SEE  TABLE  1 


Provider's  Hours: 

12.00 

***  VALID  UIC  *** 

1) 

00000  -  HQ  &  LB  CLINIC 

— 

2) 

55555  -  PORT  NEVERSAIL 

(1) 

Original 

1 

3) 

55544  -  POINT  HERE 

(2) 

Correction 

|  Select 

4) 

51515  -  CHINA 

(3) 

resubmission 

1  d-3)? 

5) 

99999  -CO  BEACH 

0) 

RETURN  TO  MAIN  MENU 

SELECT  (0-5)?  1 

IS  DATA  CORRECT  (Y/N)? 


Figure  17.  HQ  OCR  DIRS  SCREEN 
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The  first  step  in  running  this  procedure  is  selecting  a 
UIC  which  represents  the  reporting  branch  clinic.  Step 
number  2  is  to  enter  the  facility's  name.  Step  3  is  the 
provider's  hour  field  from  your  monthly  MEPRS  report.  Step 
4  is  a  selection  representing  the  status  of  the  report.  An 
original  report  is  the  first  submission  for  the  reporting 
period.  A  correction  is  a  submission  to  add,  delete  or 
correct  data  detected  locally  or  by  the  OCR  reader.  Since 
corrected  reports  are  not  supposed  to  duplicate  data,  the 
corrected  reports  will  have  to  be  typed  manually.  Corrected 
reports  consist  of  applicable  changes  only;  (i.e.,  additions 
or  deletions  for  specific  treatment  codes) .  A  resubmission 
is  the  forwarding  of  one,  several,  or  all  pages  to  MEDCOM- 
633  that  were  not  read  by  OCR  reader.  A  resubmission  does 
not  have  to  performed  manually.  The  last  step  is  a 
validation  field  asking  you  to  enter  a  "Y"  (yes)  or  "N"  (no) 
if  the  data  is  correct.  Should  you  enter  a  no,  you  will  be 
asked  to  select  a  UIC,  or  if  you  so  desire  at  this  time  exit 
this  routine.  When  lining  up  the  DIRS  form  in  the  OCR 
printer,  a  lot  of  trial  and  error  may  be  necessary  at  first 
to  line  up  the  form  exactly.  Once  lined  up,  it  is  highly 
recommended  that  you  mark  your  printer  so  that  next  time  you 
will  know  exactly  where  to  line  up  the  form.  The  ideal 
line-up  is  identified  when  an  "L"  is  typed  right  on  top  of 
the  OCR  FORM  "L." 

B.  PROVIDER  STATS. 

The  Provider  Stats  option  at  the  Headquarters  level  is 
a  compilation  of  all  subordinate  DTF's  Provider  Stats 
reports.  This  routine  is  identical  to  the  routine  described 
for  individual  providers'  stats.  The  only  exception  is  that 
this  report  reflects  the  entire  command.  An  example  of  the 
Provider  Stats  Report  is  provided  in  Appendix  K. 

C.  START  NEW  YEAR  (HQ  ONLY) . 

The  "START  NEW  YEAR  (HQ  ONLY)"  option  provided  on  the 
Headquarters  menu  is  identical  in  function  to  that  provided 
by  the  "START  NEW  YEAR"  option  for  subordinate  DTFs  except 
that  it  only  reinitializes  the  headquarter's  database.  As 
previously  discussed,  this  option  is  used  to  initialize 
records  to  zero,  providing  recordkeeping  functions  for  a  new 
reporting  year;  either  calendar,  fiscal  or  other  arbitrary 
selection. 


8.  QUIT. 

As  you  probably  have  figured  out  the  "Q"  (QUIT)  option 
exits  your  system  and  returns  you  to  the  DOS  prompt. 
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